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Chapter  1 


Introduction 


1.1  Cryptographic  Protocols 

In  computer  networks,  cryptography  is  used  to  protect  private  messages  and 
to  authenticate  the  source  and  content  of  messages.  Security  objectives  may 
take  a  sequence  of  several  messages,  that  is,  a  protocol,  to  achieve.  A  pro¬ 
tocol  can  be  specified  diagrammatically  as  in  Figure  1.1.  This  particular 
protocol  is  supposed  to  establish  a  session  between  principals  A  and  B  in 
such  a  way  that  each  principal  authenticates  the  identity  of  the  other  princi¬ 
pal,  and  they  share  two  session-specific  secrets  Na  and  iV^,  (This  is  actually 
not  the  whole  protocol  in  [NS78],  but  just  the  handshake  that  comes  after 
an  earlier  part  in  which  the  public  keys  axe  obtained.) 


{A.N3}pB 

{Na.fi  }PA 

B 

A 

n}pB 

.  .  ^ 

Figure  1.1:  Needham-Schroeder  Public-Key  Protocol 

The  bracketed  term  {A^Na}pB  represents  the  encryption  of  the  concatena¬ 
tion  of  A  and  Na  using  the  public  key  of  B,  It  is  assumed  here  that  A  has 
previously  obtained  ^’s  public  key  and  that  only  B  has  the  corresponding 
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secret  key,  and  vice  versa  for  J5.  The  message  fields  Na  and  Nt  are  nonces, 
meaning  that  they  are  fresh,  in  the  sense  that  they  have  not  been  used  before 
by  the  principal  that  originates  them.  If  they  are  large  enough  and  randomly 
generated,  they  could  be  used  as  keys  to  encrypt  subsequent  messages. 

The  secrecy  claim  is  based  on  the  argument  that  A  has  given  Na  directly 
only  to  B,  because  only  B  could  have  decrypted  the  message  in  which  Na 
was  introduced.  Similarly  for  B  and  Ni,.  The  protocol  also  provides  entity 
authentication,  i.e.,  evidence  that  the  other  principal  is  currently  actively 
participating  in  the  protocol,  because  it  includes  acknowledgments  from  B 
and  A  containing  the  nonces  they  received. 

The  same  protocol  is  often  represented  in  a  more  algebraic  style,  like  this: 

A^B:{A,Na}pB 
B  A:  {Na,  Nif}pA 
A  B  :  {Nb}pB 

CAPSL  is  an  outgrowth  of  this  algebraic  message-list  style. 


1.2  Message  Modification  Attacks 

There  is  a  message  modification  attack  on  the  Needham-Schroeder  protocol, 
found  by  Lowe  [Low96].  Message  modification  attacks  assume  that  there  is 
an  intruder  or  attacker  in  the  network  who  can  intercept  messages,  record 
them,  and  replace  them  with  modified  or  different  messages,  which  may 
appear  to  have  come  from  different  sources.  The  intruder  may  also  act  as 
a  legitimate  principal,  either  because  he  is  one,  or  because  he  has  some¬ 
how  obtained  a  long-term  secret  key  of  one.  Lowe’s  attack  is  illustrated  in 
Figure  1.2. 

In  this  figure,  the  center  column  represents  the  intruder  playing  two  roles. 
One  role  is  as  himself,  principal  X,  responding  to  A  in  the  left-hand  session 
of  the  protocol.  The  intruder  is  also  masquerading  as  A  in  the  right-hand 
session  of  the  protocol,  indicated  with  {A)  in  parentheses.  There  is  a  security 
breach  in  the  right-hand  session,  because  B  ends  up  believing  he  has  been 
talking  to  A,  and  that  N^  is  shared  only  with  A. 
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Figure  1.2:  Lowe’s  Attack 


1.3  Specification  and  Analysis  Tools 

The  existence  of  message  modification  attacks  led  to  the  development  of 
methods  to  detect  them.  Several  approaches  have  been  developed,  as  rep¬ 
resented  by  papers  such  cts  [MCF87,  Mea91]  on  goal-directed  state  search 
tools  implemented  in  Prolog,  [Kem89,  Pau98]  on  the  application  of  general- 
purpose  specification  and  verification  tools,  [BAN90,  GNY90]  on  specially 
designed  logics  of  belief,  and  [Ros95,  Low96,  CJM98]  on  the  application 
of  model-checking  tools.  This  is  far  from  a  complete  list  of  papers  on  the 
subject. 

These  tools  and  their  successors  have  been  effective,  but  it  is  difficult  for 
analysts  other  than  their  developers  to  apply  them.  One  reason  for  this 
difficulty  is  that  the  protocols  must  be  respecified  for  each  technique,  and  it 
is  not  easy  to  transform  the  published  description  of  the  protocol  into  the 
required  formal  system. 

Some  tool  developers  began  work  on  translators  or  compilers  that  would 
perform  the  transformation  automatically.  The  input  to  any  such  transla¬ 
tor  still  requires  a  formally  defined  language,  but  it  can  be  made  similar 
to  the  message-oriented  protocol  descriptions  that  are  typically  published. 
This  approach  was  taken  with  an  earlier  version  of  CAPSL  [Mil97];  ISL, 
supporting  an  application  of  HOL  to  an  extension  of  the  GNY  logic  [Bra97]; 
Casper  [Low98],  for  the  application  of  FDR  using  a  CSP  model-checking  ap¬ 
proach;  and  Carlsen’s  “Standard  Notation”  [Car94],  which  was  translated 


3 


to  per-process  CKT5  specifications. 

A  proposal  for  CAPSL  was  first  presented  at  the  1996  Isaac  Newton  Insti¬ 
tute  Programme  on  Computer  Security,  Cryptology,  and  Coding  Theory  at 
Cambridge  University.  A  version  of  CAPSL  very  close  to  the  current  one 
was  subsequently  implemented  as  an  interface  to  the  NRL  Protocol  Analyzer 
[BMM99]. 

The  CAPSL  language  and  supporting  tools  are  still  under  development.  This 
document  offers  a  snapshot  of  the  current  design,  not  only  for  CAPSL  itself, 
but  also  for  the  strategy  by  which  CAPSL  can  be  adapted  for  use  by  various 
protocol  analysis  tools.  The  core  of  this  strategy  is  the  use  of  an  intermediate 
language,  CIL,  that  is  closer  to  the  state-transition  representation  used  by 
almost  all  of  these  tools.  An  overview  of  the  CAPSL  and  CIL  environment 
was  given  in  [DM00].  Current  documentation,  the  translator,  and  other 
resources  are  available  on  the  CAPSL  Web  site  [MilOObj. 


1.4  CAPSL  Features 

The  acronym  “CAPSL”  stands  for  “Common  Authentication  Protocol  Spec¬ 
ification  Language.”  The  language  is  intended  to  support  analysis  of  cryp¬ 
tographic  protocols  using  formal  methods. 

The  core  of  a  CAPSL  specification  is  a  message  section  showing  the  ab¬ 
stract  format  of  a  sequence  of  messages.  Message  fields  are  named  and  their 
types  are  indicated,  but  details  such  as  field  lengths  and  bit  patterns  are 
not  shown.  Only  that  information  essential  for  protocol  failure  analysis  is 
retained,  resulting  in  a  clear,  simple  model  of  the  protocol. 

Encryption  operators,  hash  functions,  and  other  computations  are  treated  as 
abstract  operators  whose  properties  are  specified  axiomatically  in  auxiliary 
abstract  data  type  specifications.  Specifications  for  some  popular  opera¬ 
tors,  representing  the  abstract  features  of  cryptosystems  like  DES,  RSA, 
and  Diffie-Hellman,  are  included  in  a  prelude  file  supplied  with  the  CAPSL 
translator. 

Sometimes  the  protocol  requires  computations  and  tests  that  are  not  con¬ 
veniently  expressed  using  just  the  message  sequence.  In  CAPSL,  one  can 
insert  assignment  statements  and  equations  representing  computations  and 
tests. 
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An  important  part  of  the  protocol  specification  is  a  statement  of  its  security 
objectives.  There  is  a  “GOALS”  section  for  this  purpose,  which  may  include 
secrecy  and  belief  statements.  Initial  assumptions  axe  also  specified  formally 
and  placed  in  a  section  prior  to  the  message  list.  It  is  possible  to  place 
assertions  within  the  message  list  as  well,  to  indicate  intermediate  goals  or 
message  idealizations,  to  help  support  belief  logic  analysis. 

Finally,  there  is  also  a  way  to  specify  scenario  details  to  support  search  tools 
that  require  setup  of  individual  sessions. 


1.5  The  Intermediate  Language  CIL 


The  CAPSL  Intermediate  Language  (CIL)  serves  two  purposes:  to  help 
define  the  semantics  of  CAPSL,  and  to  act  as  an  interface  through  which 
protocols  specified  in  CAPSL  can  be  analyzed  using  a  variety  of  tools. 

The  idea  is  illustrated  in  Figure  1.3.  CAPSL  is  parsed  and  translated  to  CIL, 
and  there  axe  different  translators,  called  connectors^  from  CIL  to  whatever 
form  is  required  for  each  tool.  CIL  is  designed  to  make  the  translation  to 
tool-specific  representations  as  easy  as  possible.  The  translator  from  CAPSL 
to  CIL  can  deal  with  the  universal  aspects  of  input  language  processing,  such 
as  paxsing,  type  checking,  and  unraveling  a  message-list  protocol  description 
into  the  underlying  separate  processes. 

Fortunately,  the  protocol  specifications  required  for  most  protocol  analysis 
tools  have  considerable  structural  similarity.  They  generally  specify  a  proto¬ 
col  with  state-transition  rules  for  communicating  processes.  CIL  uses  multi¬ 
set  term  rewriting  rules  that  permit  state  changes  to  be  presented  concisely, 
and  in  a  way  that  closely  matches  the  requirements  of  analysis  tools.  This 
approach  was  influenced  by  an  analysis  example  using  Maude,  by  Denker, 
Meseguer,  and  Talcott,  presented  at  a  LICS  ’98  workshop  [DMT98a],  and  by 
Mitchell’s  multiset  rewriting  formulation,  presented  at  a  Computer  Aided 
Verification  workshop  in  1998,  and  also  later,  in  more  detail,  in  [CDL'^99]. 


1.6  Summary  of  This  Document 

Chapter  2  introduces  the  CAPSL  language  with  a  tutorial  including  a  se¬ 
quence  of  simple  examples.  It  then  goes  on  to  present  the  elements  of  the 
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Figure  1.3:  Overview  of  the  Environment 


syntax  systematically.  Chapter  3  describes  CIL  and  its  relation  to  the  un¬ 
derlying  abstract  rewriting  model.  It  also  presents  the  algorithm  for  trans¬ 
lating  CAPSL  to  CIL,  and  in  particular  the  way  the  rewrite  rules  are  gener¬ 
ated.  Chapter  4  explains  the  optimization  step,  which  reduces  the  number 
of  rewrite  rules  almost  in  half.  Then,  Chapter  5  addresses  the  integration 
of  CAPSL  and  CIL  with  analysis  tools,  using  connectors.  Analysis  tech¬ 
niques  for  PVS  and  Maude  are  summarized,  and  the  connector  to  Athena 
is  described.  There  is  a  short  conclusion,  Chapter  6.  The  report  has  several 
appendices  containing  examples  and  reference  information. 
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Chapter  2 

CAPS! 


A  CAPSL  specification  is  made  up  of  three  kinds  of  modules:  typespec^ 
protocol^  and  environment  specifications,  usually  in  that  order.  Typespecs 
declare  cryptographic  operators  and  other  functions  axiomatically.  Environ¬ 
ment  specifications  are  optional;  they  are  used  to  set  up  particular  network 
scenarios  for  the  benefit  of  search  tools.  Some  standard  typespecs  in  a 
prelude  file  are  automatically  utilized  by  the  CAPSL  translator,  so  many 
protocols  can  be  specified  with  only  a  protocol  module. 

This  introduction  to  the  CAPSL  language  begins  with  a  tutorial  sequence 
of  protocols  designed  to  illustrate  the  basic  features  of  CAPSL. 

2.1  CAPSL  Tutorial 

Here  is  the  simplest  example  of  a  protocol  specification. 

PROTOCOL  Simplel; 

VARIABLES 

A:  Principal; 

MESSAGES 

A  ->  A:  A; 

END; 

Protocol  Simplel  has  only  one  message,  in  which  principal  A  sends  its  name 
to  itself.  As  in  a  strongly  typed  programming  language,  variables  must  be 
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declared  and  typed.  Principals  are  objects  that  can  occur  as  the  source  or 
destination  of  a  message. 

Here  is  a  slightly  more  complex  example. 

PROTOCOL  Simple2; 

VARIABLES 

A,  B:  Principal; 

ASSUMPTIONS 
HOLDS  A:  B; 

MESSAGES 

A  ->  B:  A; 

END; 

The  HOLDS  declaration  states  that  the  process  executing  on  behalf  of  A  has 
been  initialized  with  the  principal  B  chosen  as  the  responder.  Read  it  as 
“A  holds  B.”  If  the  HOLDS  assumption  is  omitted,  the  CAPSL  translator 
will  complain  that  sender  of  the  first  message  does  not  know  the  receiver 
address.  It  is  unnecessary  to  say  HOLDS  A:  A  because,  by  convention,  prin¬ 
cipals  always  hold  themselves. 

2.1.1  Encryption 

Certain  types  of  principals  possess  long-term  keys.  PKUser  is  a  subtype  of 
Principal  possessing  a  public  key  pair.  If  A  is  of  type  PKUser,  pk(A)  is  its 
public  key  and  sk(A)  the  corresponding  private  (secret)  key.  Thus,  A  could 
encrypt  its  message  to  B  as  follows: 

PROTOCOL  SimpleS; 

VARIABLES 

A,  B:  PKUser; 

ASSUMPTIONS 
HOLDS  A:  B; 

MESSAGES 

A  ->  B:  {A}pk(B); 

END; 

The  notation  {fieldjkey  is  syntactic  sugar  for  the  function  call  ped{key, field). 
The  function  ped  is  the  standard  abstract  public  key  encryption  and  decryp¬ 
tion  function.  (If  the  key  is  a  symmetric  key,  the  syntactic  sugar  expands 
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internally  into  a  call  on  se,  the  standard  abstract  symmetric  key  encryption 
function,  instead.) 

2.1.2  Fresh  Keys 

Session  keys  are  usually  assumed  to  be  fresh,  generated  in  some  way  that 
ensures  (up  to  a  cryptographically  unlikely  coincidence)  that  each  new  one 
has  not  been  used  before.  To  be  useful  as  a  key,  the  new  value  should  be 
unguessable.  Sequence  numbers,  for  example,  are  fresh  but  not  unguessable. 
Here  is  an  example  of  session  key  generation: 

PROTOCOL  Simple4; 

VARIABLES 

A,  B:  Principal; 

K:  Skey,  FRESH,  CRYPTO; 

ASSUMPTIONS 
HOLDS  A:  B; 

MESSAGES 

A  ->  B:  {A>K; 

END; 

In  this  example,  Skey  is  a  symmetric  key  type,  and  the  declaration  of  K  has 
two  keywords  FRESH  and  CRYPTO  called  properties.  The  CRYPTO  property 
indicates  unguessability. 

Simple4  is  not  useful  because  B  does  not  hold  K  and  cannot  decrypt  the 
message  to  obtain  A.  In  CAPSL,  this  protocol  specification  is  semantically 
illegal  because  it  implies  that  B  decrypts  the  message,  and  the  translator 
will  complain  that  the  message  is  not  “receivable”  by  B.  Declaring  that  B 
holds  K  does  not  work,  because,  in  the  first  message,  A  cannot  generate 
K  as  a  fresh  value  if  it  is  already  held  by  and  the  translator  complains 
accordingly.  But  there  is  a  way  to  specify  that  B  does  not  try  to  decrypt 
the  message. 

2.1.3  The  Lowe  %-Operator 

The  author  of  the  protocol  can  specify  that  B  accepts  the  encrypted  term 
without  attempting  to  decrypt  it,  by  declaring  a  variable  in  which  B  stores 
the  received  value.  The  different  views  of  the  message  -  the  encrypted  form 


seen  by  A  and  the  atomic  form  seen  hy  B  -  are  separated  by  the  %  operator, 
which  was  introduced  by  Lowe  in  Casper  [Low98].  We  can  see  how  the  % 
operator  is  used  in  this  version  of  the  protocol: 

PROTOCOL  SimpleS; 

VARIABLES 

A,  B:  Principal; 

K:  Skey,  FRESH,  CRYPTO; 

F:  Field; 

ASSUMPTIONS 
HOLDS  A:  B; 

MESSAGES 

A  ->  B:  ({A}K)%F; 

END; 

The  type  Field  is  the  supertype  of  all  types  that  can  be  used  as  message 
fields,  including  principals,  keys,  and  terms  constructed  by  encryption  and 
concatenation. 

The  %-operator  has  a  weaker  binding  precedence  than  encryption,  so,  for 
example,  ({A}K)%F  can  safely  be  written  as  {A}K%F. 


2.1.4  Address  Convention 

Suppose  we  wish  to  extend  SimpleS  to  a  longer  protocol  in  which  B  replies 
to  A  with  F. 


PROTOCOL  SimpleG; 

VARIABLES 

A,  B:  Principal; 

K;  Skey,  FRESH,  CRYPTO; 
F:  Field; 

ASSUMPTIONS 
HOLDS  A;  B; 

MESSAGES 

A  ->  B:  {A}Ky,F; 

B  ->  A:  F; 

END; 
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The  reply  message  is  unacceptable  to  the  CAPSL  translator  because  “sender 
does  not  know  receiver  address.”  The  problem  here  is  that  since  B  can’t 
decrypt  the  message,  B  has  not  learned  the  value  of  A.  By  convention,  the 
source  address  of  the  message  is  not  considered  part  of  the  content,  and  is 
not  readable  by  the  receiver  of  the  message.  Realistically,  this  seems  reason¬ 
able  because,  although  the  same  “Principal”  type  is  used  in  the  abstraction 
in  both  the  address  and  content  portions  of  the  message,  implementations 
distinguish  an  address  specification  -  such  as  an  IP  address  -  from  a  sub¬ 
ject  name,  which  is  a  text  string  chosen  to  be  meaningful  in  the  application 
context.  Protocols  presented  in  the  literature  are  inconsistent  with  regard 
to  this  convention. 

2.1.5  Goals 

In  order  to  analyze  the  security  of  a  protocol,  there  must  be  a  statement  of 
its  objectives.  In  CAPSL,  there  is  a  GOALS  section  to  express  secrecy  and 
authentication  claims.  In  the  following  simple  example  protocol,  we  might 
imagine  that  the  designer  intended  for  if  to  be  a  secret  shared  only  by  A 
and  and  that  when  B  receives  it,  B  can  be  assured  that  it  was  sent  by 
A. 

These  two  goals  axe  stated  as  SECRET  and  PRECEDES  assertions.  A  SECRET 
assertion  says  that  the  value  of  a  variable  generated  by  its  nominal  originator 
cannot  be  obtained  by  the  intruder  (unless  the  intruder  is  acting  in  one  of 
the  legitimate  roles  of  the  protocol).  A  PRECEDESA,  B|Pi,  F2, ...  assertion 
says  that  if  B  reaches  its  final  state,  then  A  must  have  reached  a  state  that 
agrees  with  B  on  Vi,  F2, .... 


PROTOCOL  Simple?; 

VARIABLES 

A,  B:  Principal; 

K:  Skey,  FRESH,  CRYPTO; 
F:  Field; 

ASSUMPTIONS 
HOLDS  A:  B; 

MESSAGES 

A  ->  B:  {A,K}pk(B); 
GOALS 

SECRET  K; 
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PRECEDES  A:  B  I  K; 

END; 

In  this  protocol,  K  as  generated  by  A  is  kept  secret,  but  it  might  not  reach 
The  message  received  by  B  could  have  been  forged  by  the  intruder.  Thus, 
the  value  of  K  received  by  B  is  not  necessarily  from  A,  so  the  PRECEDES 
goal  would  fail. 


2.1,6  The  Needham-Schroeder  Public  Key  Handshake 

This  tutorial  concludes  with  the  CAPSL  specification  of  the  Needham- 
Schroeder  public  key  handshake  mentioned  in  the  Introduction.  There  is 
a  type  Nonce  used  in  this  protocol  which  is  assumed  implicitly,  by  conven¬ 
tion,  to  have  the  property  FRESH  (but  not  necessarily  CRYPTO). 


PROTOCOL  NSPK; 

VARIABLES 

A,  B:  PKUser; 

Na,  Nb:  Nonce,  CRYPTO; 
ASSUMPTIONS 
HOLDS  A:  B; 

MESSAGES 

A  ->  B:  {A,Na}pk(B); 

B  ->  A:  {Na,Nb}pk(A); 

A  “>  B:  {Nb}pk(B); 
GOALS 

SECRET  Na; 

SECRET  Nb; 

PRECEDES  A:  B  I  Na; 
PRECEDES  B:  A  I  Nb; 
END; 


2.2  Types  and  Declarations 

Typespecs  define  the  types  and  operators  used  in  protocol  specifications. 
There  is  a  subtype  relation  that  places  types  in  a  hierarchy.  Both  typespecs 
and  protocol  specifications  can  declare  types,  constants,  functions,  and  vari- 
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ables.  The  difiference  is  that  declarations  appearing  in  typespecs  are  uni¬ 
versal  and  re-usable,  while  those  in  protocol  specifications  are  specific  to  a 
protocol.  Before  describing  typespecs  protocol  specifications,  we  present  the 
type  hierarchy  and  show  the  kinds  of  declarations  that  may  appear  in  either 
typespecs  or  protocol  specifications. 


2.2.1  The  Type  Hierarchy 

Messages  in  cryptographic  authentication  protocols  are  constructed  using 
cryptographic  operators  and  other  functions,  such  as  concatenation  and  hash 
functions.  Every  message  field  is  of  type  Field,  but  certain  operators  require 
or  produce  fields  of  particular  subtypes,  such  as  key  types.  Field  is  a  subtype 
of  the  universal  type  Object,  and  there  are  other  types  of  objects  that  are 
not  used  as  message  fields,  such  as  Role,  Spec  and  Boolean.  A  portion  of 
the  type  hierarchy  is  shown  in  Figure  2.1. 

Object 


Field  Role  Boolean  Spec 


Tape  Atom  List  Pspec  Tspec  Espec 


Principal  Skey  Pkey  Nonce 

I 

PKUser 

Figure  2.1:  The  Type  Hierarchy 

In  principle,  all  functions  used  in  CAPSL  and  the  data  types  they  oper¬ 
ate  on  must  be  specified  axiomatically  in  typespecs.  The  types  that  are 
shown  in  the  hierarchy  and  the  most  commonly  used  encryption  operators 
axe  included  in  the  prelude.  The  current  prelude  is  given  in  Appendix  B. 
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2.2.2  Declarations 


Declarations  include  IMPORTS,  TYPES,  VARIABLES,  FUNCTIONS,  and 
CONSTANTS,  in  no  particular  order  except  that  identifiers  must  be  declared 
before  they  are  used. 

IMPORTS.  An  IMPORTS  declaration  names  one  or  more  specifications 
(this  is  one  reason  why  specifications  are  named)  and  indicates  that  the 
declarations  contained  in  them  or  imported  by  them  are  to  be  used  as  though 
they  were  included  in  the  present  specification.  An  IMPORTS  declaration 
permits  the  CAPSL  translator  to  process  a  sequence  of  specifications  and 
check  that  imported  specifications  have  occurred  earlier  in  the  sequence. 
The  CAPSL  translator  assumes  that  user  specifications  implicitly  import 
the  whole  prelude,  so  that  it  is  not  necessary  to  import  any  specification  in 
the  prelude  explicitly. 

Importation  of  declarations  brings  all  symbols  into  the  same  context.  One 
may  not,  for  example,  declare  the  same  function  or  variable  twice;  a  “du¬ 
plicate  declaration”  error  message  will  result.  There  are  three  exceptions 
to  this,  as  noted  below,  for  function  overloading,  function  refinement,  and 
dummy  variables, 

TYPES.  A  type  declaration  TYPES  Ti, ...  :  T; ...  introduces  new  types  Ti, ... 
and  indicates  that  they  are  subtypes  of  T.  The  supertype  is  optional,  and  if 
it  is  left  out,  the  new  types  are  assumed  to  be  subtypes  of  Atom  (a  generic 
fixed- length  field  type). 

VARIABLES.  A  variable  declaration  VARIABLES  Vl,  ...  :  T,  Fi, ...  intro¬ 
duces  protocol  variables  of  type  T,  optionally  with  properties  Pi,....  The 
FRESH  and  CRYPTO  properties  were  mentioned  above;  others  will  be  intro¬ 
duced  where  they  are  relevant. 

A  variable  declared  in  a  typespec  is  a  dummy  variable,  and  the  same  variable 
may  be  redeclared  as  the  same  type  in  another  typespec.  A  variable  declared 
in  a  protocol  specification  is  a  protocol  variable  and  it  may  not  also  be 
declared  elsewhere.  (A  future  version  of  the  CAPSL  translator  may  treat 
dummy  variable  declarations  as  local  to  permit  redeclaration  in  another 
context.) 

FUNCTIONS.  A  function  declaration  FUNCTIONS  Pi(Ti, ...)  :  T2,  Pi, ...; ... 
declares  the  type  signature  of  one  or  more  functions.  Function  values  may 
have  the  properties  PRIVATE,  ASSOC,  and  COMM.  Private  functions  are  dis- 
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cussed  below  in  the  typespec  section.  The  ASSOC  and  COMM  properties  des¬ 
ignate  associative  and  commutative  binary  functions,  to  obviate  axioms  for 
that  purpose. 

The  same  function  name  may  be  re-used  for  another  function  for  the  sake 
of  either  overloading  or  refinement.  Overloading  means  that  the  function 
name  is  used  with  a  different  signature  that  does  not  overlap  with  an  ear¬ 
lier  declaration,  such  as  different  forms  of  addition  for  Skeys  and  Booleans. 
Refinement  means  that  domain  restriction  implies  a  range  restriction,  such 
as  the  refinement  of  encryption  from  fields  to  atoms,  shown  in  the  next 
subsection. 

CONSTANTS.  A  constant  is  essentially  a  function  with  no  arguments.  A 
constant  declaration  has  the  form  CONSTANTS  Ci, ...  :  Ti; .... 


2.2.3  Typespecs 

A  typespec  consists  of  some 'declarations,  followed  optionally  by  some  ax¬ 
ioms.  Typespecs  usually  introduce  a  new  type  and  some  functions  defined 
on  it,  but  in  some  cases  they  merely  extend  an  existing  typespec  by  defining 
new  functions  on  existing  types. 

Here  is  an  example  of  some  related  typespecs  found  in  the  prelude. 

TYPESPEC  PKEY; 

TYPES  Pkey; 

END; 

TYPESPEC  SPKE; 

IMPORTS  PKEY; 

FUNCTIONS 

ped(Pkey,  Field):  Field; 
ped(Pkey,  Atom):  Atom; 

END; 

TYPESPEC  PPK; 

IMPORTS  SPKE; 

TYPES  PKUser:  Principal; 

FUNCTIONS 

pk (PKUser):  Pkey; 
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sk(PKUser):  Pkey,  PRIVATE; 

VARIABLES 

A:  PKUser; 

X:  Field; 

AXIOMS 

ped(sk(A) ,ped(pk(A) ,X))  =  X; 
ped(pk(A) ,ped(sk(A) ,X))  =  X; 

INVERT  ped(pk(A),X):  X  |  sk(A); 

INVERT  ped(sk(A),X):  X  I  pk(A); 

END; 

The  first  typespec  declares  a  data  type  Pkey  (public  key).  New  types  are 
subtypes  of  Atom  unless  otherwise  indicated.  The  second  typespec  defines 
publiC“key  encryption  using  a  single  encryption/decryption  function  ped. 
This  function  has  two  type  signatures,  a  more  general  one  for  encrypting 
fields,  and  a  more  specific  one  that  says  that  atomic  fields  are  encrypted  to 
atomic  fields.  This  is  an  example  of  function  refinement. 

The  encryption/decryption  cancellation  property  for  public-key  encryption 
is  not  stated  in  this  typespec,  because  key  pairs  will  be  generated  by  func¬ 
tions  associated  with  Principal  subtypes. 

Typespec  PPK  defines  a  subtype  PKUser  of  Principal.  PKUsers  have  two 
functions  defined  for  them  giving  their  permanent  public  and  secret  keys. 

Functions  are  normally  public  or  universal,  in  the  sense  that  anyone  can 
compute  them,  given  the  argument  values.  This  is  not  what  we  want  for  the 
secret-key  function,  for  if  anyone  could  compute  the  secret  key  sk(A)  just 
by  knowing  A,  the  secret  key  would  hardly  be  secret.  Hence  the  PRIVATE 
property. 

If  the  first  argument  of  a  function  is  of  type  Principal,  it  can  be  declared 
with  the  PRIVATE  property  to  indicate  that  the  value  is  available  only  to  the 
principal  named  in  the  first  argument.  Thus,  only  Alice  can  find  sk( Alice). 

There  are  four  axioms  in  PPK.  The  first  two  say  that  sk(A)  and  pk(A)  are 
inverse  keys  with  respect  to  ped,  in  either  order.  The  CAPSL  translator  does 
not  “understand”  these  axioms;  it  simply  passes  them  on  through  OIL  to  the 
analysis  tools.  However,  the  invertibility  properties  of  ped  are  also  expressed 
in  the  corresponding  INVERT  statements.  These  are  used  by  the  CAPSL 
translator  to  check  implementability  of  specifications.  INVERT  t :  x\y  means 
that  any  party  (either  legitimate  or  the  intruder)  holding  term  t  containing 
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a  variable  x  can  compute  x  provided  that  it  holds  y.  y  could  be  a  list  of 
terms.  The  use  of  INVERT  statements  is  covered  in  more  detail  in  Chapter  3. 

The  use  of  typespecs  to  define  subtypes  of  Principal  with  functions  to  look 
up  their  long-term  keys  is  an  important,  original  stylistic  aspect  of  CAPSL. 


2.3  Protocol  Specifications 


A  protocol  specification  has  the  form: 

PROTOCOL  name] 

declarations 

ASSUMPTIONS 

assumptions 

MESSAGES 

messages  and  actions 

GOALS 

goals 

END; 

There  is  one  special  kind  of  declaration  that  occurs  only  in  protocol  speci¬ 
fications:  DENOTES  declarations. 

2.3.1  DENOTES  Declarations 

DENOTES  declarations  allow  a  variable  to  be  defined  as  the  value  of  an  ex¬ 
pression.  This  is  helpful  in  protocols  where  there  are  certificates  or  tickets  or 
public  values  with  a  complex  structure,  and  we  want  to  define  them  initially 
and  use  a  variable  for  them  in  the  body  of  the  protocol.  A  DENOTES  decla¬ 
ration  section  can  declare  more  than  one  variable.  It  has  the  form  DENOTES 
V  =  e  :  A, where  e  is  a  term  and  A  is  a  principal.  More  than  one 
principal,  or  none,  may  be  listed. 

A  declaration  V  =  e  :  A  is  treated  as  an  assignment  action  that  is  executed 
by  A  when  V  is  first  used  by  A.  This  might  happen  when  A  is  putting  V 
into  a  message,  or  when  A  receives  a  message  purportedly  containing  V  so 
that  it  can  make  a  comparison.  A  DENOTES  action  is  used  only  once  by  each 
agent,  since  V  is  held  thereafter. 
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It  is  possible  to  omit  the  principal  from  the  DENOTES  declaration,  as  in 
DENOTES  V  =  e.  In  this  case,  all  principals  will  use  this  action. 

DENOTES  equations  must  be  placed  in  logical  order.  That  is,  if  there  is 
a  DENOTES  equation  V  =  f{X)  and  also  a  DENOTES  equation  for  X,  the 
equation  for  X  must  appear  earlier. 

The  variable  on  the  left  in  a  DENOTES  declaration  must  be  declared  sepa¬ 
rately.  It  is  a  real  protocol  variable,  not  merely  a  placeholder  for  macro 
substitution. 

DENOTES  declarations  are  helpful  when  the  same  value  is  computed  in  dif¬ 
ferent  ways  by  different  principals.  One  example  of  this  is  in  generating 
a  common  key  via  Diffie-Hellman  agreement.  Another  example  is  when  a 
long-term  key  must  be  looked  up  using  a  different  private  function  by  each 
principal. 


2.3.2  Assumptions 

Syntactically,  assumptions  include  statements  and  certain  special  forms.  As¬ 
sumption  statements  are  boolean-valued  terms  or  equalities.  The  special 
form  most  commonly  used  as  an  assumption  is  the  HOLDS  form. 

CAPSL  also  allows  statements  and  other  assumptions  to  be  qualified  with 
the  belief  operator,  e.g.,  BELIEVES  A  :  BELIEVES  B  :  HOLDS  A  :  K,  read:  “A 
believes  that  B  believes  that  A  holds  AT.”  This  syntax;  is  included  to  help 
support  belief  logic  applications  of  CAPSL.  Belief  assumptions  are  useful 
only  in  conjunction  with  a  suitable  modal  logic  to  infer  belief  goals. 

There  is  also  a  KNOWS  operator.  This  does  not  refer  to  values,  as  HOLDS  does. 
Instead,  it  is  Hintikka’s  epistemic  logic  operator,  related  to  BELIEVES.  The 
relationship  is  that  KNOWS  A  :  ^  is  equivalent  to  A  BELIEVES  A  :  (/>,  i.e., 
belief  plus  truth. 

2.3.3  Messages 

The  MESSAGES  section  of  a  protocol  specification  is  a  sequence  of  messages, 
among  which  actions  may  be  interleaved.  The  MESSAGES  section  may  end 
with  a  subprotocol  invocation.  These  are  complex  enough  subjects  so  that 
a  separate  section  is  allocated  to  discuss  them. 
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2,3.4  Goals 


The  GOALS  section  states  the  security  objectives  for  the  protocol.  Syntacti¬ 
cally,  the  same  assertions  that  are  legal  as  assumptions  are  legal  as  goals. 
However,  in  the  GOALS  section  one  expects  to  see  secrecy  and  authentication 
assertions. 

Secrecy.  A  SECRET  assertion  has  the  form  SECRET  V  :  Pi, ....  It  says  that  the 
protocol  variable  V  is  secrets  shared  only  by  the  principals  Pi,....  The  list 
of  principals  may  be  omitted,  in  which  case  it  is  understood  that  the  secrets 
are  shared  by  all  of  the  principals  playing  legitimate  roles  in  the  protocol 
session.  The  semantics  of  secrecy  assertions  is  discussed  in  depth  in  [MROO]. 
The  CAPSL  translator  does  not  yet  (at  this  writing)  introduce  “spell”  events 
as  described  in  that  paper;  it  merely  parses  the  SECRET  assertion  and  passes 
it  on  in  abstract  syntax. 

Precedence  and  Agreement.  A  PRECEDES  goal  has  the  form  PRECEDES 
A,  51^1,1^27  ••••  Intuitively,  this  says  that  if  some  instance  of  the  P  role 
reaches  its  final  state,  it  agrees  with  some  instance  of  the  A  role  on  A,  B,  Fi, 
and  V2. 

Agreement  is  like  precedence  except  that  there  is  no  existence  claim.  For 
example,  the  goal  AGREE  A,  P  :  Vi,  ...IPFi, ...;  says  that  if  there  is  any  instance 
of  A  that  agrees  with  P  on  A,  P,  Wi, ...,  then  it  must  agree  on  Vi, ...  also. 


2.4  The  MESSAGES  Section 


The  message  format  is  straightforward,  but  there  are  some  interesting  fea¬ 
tures  in  the  presentation  of  message  fields.  We  discuss  those  below.  Besides 
messages,  the  MESSAGES  section  may  contain  actions  and  subprotocol  invo¬ 
cations. 


2.4.1  Message  Format 

A  message  has  the  form 

id.  sender  ->  receiver:  fieldj  ...; 
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The  sender  and  receiver  must  be  protocol  variables  of  type  Principal,  and 
the  content  fields  are  terms  of  type  Field.  The  message  id  (and  its  associated 
period)  are  merely  decorative  and  optional.  Some  infix  operators  and  other 
notational  conveniences  have  been  introduced  to  permit  CAPSL  messages 
to  look  like  those  in  the  literature.  The  existing  infix  operators  fall  into  four 
categories:  concatenation,  encryption,  arithmetic,  and  the  %-operator. 

Concatenation,  A  sequence  of  fields  may  be  concatenated  into  a  single 
longer  field,  usually  for  the  purpose  of  having  them  encrypted  together. 
Curly  brackets  {  ,  }  and  square  brackets  [  ,  ]  denote  different  kinds  of 
concatenation,  which  are  translated  into  different  functions,  cat  and  con 
respectively,  cat  is  associative  and  con  is  not. 

Both  cat  and  con  are  binary.  Longer  concatenations  are  parsed  under  the 
assumption  that  right  association  is  intended.  Thus,  [a,  6,c]  is  parsed  as 
[a,[b,c]\. 

Associativity  of  concatenation  matters  when  we  try  to  decompose  a  concate¬ 
nation.  With  non-associative  con,  the  first  component  of  a  concatenation 
[[A,B]  ,C]  is  [A,B] .  With  associative  cat,  the  first  component  of  -[{A,B>,C} 
would  be  A,  unless  A  is  itself  a  concatenation. 

To  deal  with  this  question  we  differentiate  between  atomic  fields,  which 
form  the  subtype  Atom  of  Field,  and  those  fields  that  are  expressible  as  a 
concatenation  of  smaller  fields.  The  first  component  of  a  cat  concatenation 
is  the  first  atomic  component.  Most  types  -  all  types  in  the  prelude  except 
Field  and  List  -  are  subtypes  of  Atom. 

Note.  A  message  A  ->  B:  {C,D}  can  be  received  by  B  only  if  C  is  atomic. 
If  C  is  not  atomic,  B  cannot  parse  the  concatenation  from  left  to  right  -  it 
won’t  know  where  C  stops  and  D  begins.  The  translator  generates  an  error 
message  if  this  condition  is  not  met. 

Encryption.  Putting  a  key  after  a  bracketed  expression  denotes  encryption, 
using  ped  if  the  key  is  of  type  Pkey  or  se  if  the  key  is  of  type  Skey.  Thus, 
the  expression  {A ,  K}pk(B)  is  interpreted  as  ped (pk(B) ,  cat(A,  K)). 

A  key  after  brackets  also  indicates  encryption  even  without  a  concatenation, 
so  that  {X}K  is  interpreted  as  se(K,  X). 

Decryption  with  sd  is  indicated  with  a  prime,  for  example,  {X}'K. 

The  same  encryption  functions  are  invoked  with  square  brackets;  the  only 
difference  is  that  the  con  operator  is  used  for  the  concatenation.  There  is 
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no  difference  between  {X}'K  and  [X]  'K. 

Arithmetic.  CAPSL  permits  infix  arithmetic  operators  +,  *,  /,  and 

with  type  Skey.  These  are  automatically  translated  to  functions  pis,  mns, 
tms,  div,  and  exp,  which  appear  in  the  prelude.  The  prelude  does  not 
attempt  to  axiomatize  these  functions.  It  is  assumed  that  any  verification 
tool  that  can  deal  with  these  functions  has  its  own  understanding  of  them, 
and  the  connector  for  that  tool  will  rename  them  appropriately. 

In  protocols,  arithmetic  is  usually  finite-field  arithmetic  with  respect  to  some 
modulus.  The  value  of  the  modulus  may  be  important  for  cryptanalysis  but 
it  often  does  not  matter  for  protocol  analysis.  An  example  of  the  use  of 
these  operators,  the  SRP  protocol,  appears  in  Appendix  C. 

Arithmetic  is  used  most  often  to  compute  symmetric  keys,  and  that  is  why 
these  operators  are  defined  on  type  Skey.  It  may  be  desirable  to  broaden 
the  domain  of  arithmetic  to  all  atomic  types,  with  some  protection  against 
mixing  different  types. 

Some  protocols  add  or  subtract  one  from  a  nonce  in  a  handshake  response 
to  protect  against  replay.  They  don’t  really  need  arithmetic.  They  can  use 
any  value-changing  function.  A  protocol  can  have  a  declaration  FUNCTIONS 
inc  (Nonce) :  Nonce  if  it  needs  to  increment  a  nonce  for  this  purpose.  No 
axioms  are  needed. 

Lowe’s  %-Notation.  Sometimes  it  is  necessary  to  distinguish  between  the 
sender’s  view  of  a  message  and  the  receiver’s  view,  because  the  receiver  may 
have  more  or  less  knowledge  about  the  structure  of  a  message  field  than  the 
sender.  For  this  purpose,  we  exploit  the  %-notation  introduced  in  Casper 
[Low98]. 

A  %-term  is  a  term  of  the  form  u%v^  or  a  term  containing  some  subterm 
of  that  form.  In  the  %-term  u%u,  u  is  the  sender’s  version  of  the  term 
and  V  is  the  receiver’s  version.  A  term  like  {A/iB,  C%D}  makes  sense,  since 
the  sender  constructs  {A,  C}  and  the  receiver  sees  {B,  D},  while  a  term  like 
Ay,{cy,D}K  does  not  make  sense.  No  %  should  be  within  the  scope  of  another. 
Any  %-term  could  be  written  equivalently  with  only  a  single  top-level  use 
of  %.  The  precedence  of  %  is  lower  than  that  of  any  other  operator  except 
a  comma  separating  fields. 
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2.4.2  Actions 


An  action  is  an  statement  that  occurs  in  a  message  list.  An  equational  action 
like  X  =  e  may  be  either  an  assignment  that  sets  A  or  a  comparison  test, 
depending  on  whether  or  not  the  agent  already  holds  X  in  that  state.  If  X 
is  held,  the  equation  can  only  be  a  comparison  test,  because  variables  do 
not  change  value.  But  if  X  is  not  held,  the  equation  must  be  an  assignment, 
since  it  would  be  undefined  as  a  test.  If  there  is  a  term  other  than  a  variable 
on  the  left,  the  action  must  be  a  comparison  test.  (However,  in  the  future 
CAPSL  may  support  assignment  into  an  element  of  an  array,  and  then  the 
expression  on  the  left  will  be  an  indexed  variable.) 

CAPSL  can  handle  an  equation  with  a  concatenation  of  variables  on  the 
left,  such  as  {A,  B}  =  e.  This  is  expanded  into  two  equations,  in  this  case 
A  =  f  irst(e);  B  =  rest(e). 

The  result  of  a  failed  comparison  test,  incidentally,  or  the  evaluation  of  any 
other  kind  of  statement  to  false,  is  that  the  acting  agent  does  not  make  any 
further  state  transitions.  That  is,  it  crashes  silently.  If  the  failure  of  the  test 
is  supposed  to  generate  an  error  reply,  that  must  be  indicated  explicitly  in 
the  protocol  specification,  using  the  conditional  selection  syntcix  discussed 
below. 

Actions  may  also  be  of  the  form  ASSUME  statement  or  PROVE  statement. 
These  are  essentially  assumptions  and  goals,  respectively,  except  that  they 
are  associated  with  intermediate  states  rather  than  with  initial  and  final 
states. 


2.4.3  Phrases 


When  processing  an  action,  the  CAPSL  translator  must  determine  which 
agent  (actually,  which  role)  is  taking  the  action,  so  that  it  can  determine 
which  variables  are  held.  The  acting  agent  is  usually  apparent  from  the 
position  of  the  action  in  the  message  list.  For  example,  in  the  message-list 
fragment 


A  ->  B:  X; 
X  =  Y; 

B  ->  C:  Z; 
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it  is  obviously  B  who  executes  the  action  X  =  Y.  But,  what  if  two  messages 
in  a  row  are  sent  by  the  same  agent?  For  example, 


A  ->  B:  X; 
X  =  Y; 

A  ->  C:  Z; 


Now  it  is  not  clear  whether  the  action  is  taken  by  B  after  receiving  the 
first  message,  or  by  A  before  sending  the  next.  The  ambiguity  is  resolved 
in  CAPSL  by  inserting  a  slash  “/”  as  a  phrase  divider  to  separate  receiver 
actions  from  sender  actions.  In  this  case,  if  we  intended  that  the  action  be 
performed  by  B,  we  would  write: 


A  ->  B:  X; 
X  =  Y;/ 

A  ->  C:  Z; 


The  term  “phrase”  refers  to  a  message  and  the  actions  before  and  after  it 
by  its  sender  and  receiver.  Invocations  and  selections,  explained  in  the  next 
subsection,  are  also  phrases. 


2.4.4  Subprotocols  and  Selection 

Some  complex  protocols  are  actually  frameworks  that  guide  a  communica¬ 
tion  session  through  a  sequence  of  “exchanges”  or  subprotocols.  A  subpro¬ 
tocol  is  a  way  to  encapsulate  a  logically  cohesive  sequence  of  messages.  In 
CAPSL,  a  subprotocol  is  just  a  separate  protocol  module. 

A  protocol  Pi  may  invoke  another  one,  say  P2,  by  using  an  INCLUDE  P2 
phrase  (called  an  invocation)  in  place  of  a  message.  The  two  protocol  spec¬ 
ifications  would  occur  in  the  order  Pi,P2,  so  that  variables  defined  in  Pi 
may  be  imported  and  used  in  P2.  The  name  P2  should  be  declared  in  Pi 
as  a  constant  of  type  Pspec.  The  outline  of  invocation  use  is  something  like 
this: 

PROTOCOL  PI; 

CONSTANTS  P2:  Pspec; 

MESSAGES 
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INCLUDE  P2; 

END; 

PROTOCOL  P2; 

IMPORTS  PI; 

END; 

Conditional  Selection.  The  selection  of  later  subprotocols  may  be  con¬ 
ditional  on  data  values  or  agreements  reached  in  earlier  message  exchanges. 
Another  reason  for  conditional  branching  in  a  protocol  might  be  to  provide 
an  error  reply  as  an  alternative  to  a  normal  continuation  after  some  test 
fails.  In  CAPSL,  a  conditional  expression  selecting  alternative  invocations 
is  called  a  selection.  An  alternative  in  a  selection  could  be  any  kind  of 
phrase,  so  it  could  be  a  message,  an  invocation,  or  a  nested  selection.  The 
SSL  example  in  Appendix  C  illustrates  how  this  is  done.  Here  is  an  outline 
of  how  a  selection  is  used: 

PROTOCOL  PI; 

CONSTANTS  P2:  Pspec; 

MESSAGES 

IF  A  =  B  THEN  INCLUDE  P2; 

ELSE  INCLUDE  P3;  ENDIF; 

END; 

PROTOCOL  P2; 

IMPORTS  PI; 

END; 

PROTOCOL  P3; 

IMPORTS  PI; 

END; 

There  is  a  problem,  in  principle,  with  continuing  a  protocol  with  more  mes¬ 
sages  after  a  selection  with  alternative  subprotocols.  Different  subprotocols 
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may  cause  different  sets  of  program  variables  to  become  held.  The  legality 
and  meaning  of  subsequent  messages  is  then  ambiguous. 

Presently,  CAPSL  deals  with  this  problem  in  a  rather  draconian  way  by 
requiring  that  no  statement  may  follow  an  INCLUDE,  even  when  there  is  no 
selection.  Invocations  can  be  chained,  however,  to  achieve  sequencing.  For 
example,  protocol  P2  in  the  outlines  above  could  contain  another  invocation 
at  the  end  of  its  MESSAGES  section. 

A  more  advanced  treatment  of  subprotocol  invocation  would  be  to  give  them 
arguments  so  that  they  could  have  their  own  protocol  variable  contexts,  just 
as  program  subroutines  do.  At  the  moment,  this  feature  would  probably 
outstrip  the  capabilities  of  protocol  analysis  tools.  Analysis  is  simpler  if 
we  assume  that  subprotocols  do  not  “return,”  they  just  take  over  from  the 
parent  session. 


2.5  Environment  Specifications 

When  a  protocol  is  being  analyzed  or  simulated,  the  analyst  may  have  to 
specify  which  agents  are  to  be  run.  The  analyst  may  also  have  to  sup¬ 
ply  other  run-specific  information  such  as  the  initial  knowledge  of  the  at¬ 
tacker.  CAPSL  specifications  can  include  ENVIRONMENT  specifications  con¬ 
taining  this  kind  of  information.  Each  environment  specification  sets  up  a 
different  scenario  for  analysis.  An  environment  specification  contains  dec¬ 
larations,  one  or  more  AGENT  sections,  and,  optionally,  any  of  an  EXPOSED 
section,  an  AXIOMS  section,  and  an  ORDER  section. 

An  environment  specification  defines  constants  for  principals  and  perhaps 
other  values  like  compromised  keys.  The  specification  constructs  agents  by 
naming  the  principal,  role,  and  initial  values  for  each  agent. 

Declarations  to  name  principals  and  other  constants  could  be  placed  in  this 
section.  For  example,  suppose  we  want  two  principals,  Alice  and  Bob,  taking 
the  usual  ‘A’  and  ‘B’  roles,  and  Mallory  as  a  dishonest  principal.  We  might 
set  that  up  like  this: 

ENVIRONMENT  Testl; 

IMPORTS  NSPK; 

CONSTANTS 

Alice,  Bob:  PKUser; 
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Mallory:  PKUser,  EXPOSED; 

AGENT  A1  HOLDS 
A  =  Alice; 

B  =  Bob; 

AGENT  B1  HOLDS 
B  =  Bob; 

EXPOSED 

{Bob}sk(Alice) ; 

END; 

An  environment  specification  imports  the  protocol  specification  it  applies 
to,  in  order  to  refer  to  its  protocol  variables  (A,  etc.).  Agents  are  named 
(this  is  an  implicit  declaration  of  a  constant  of  type  Agent)  and  constants 
must  be  given  as  values  for  the  protocol  variables  initially  held  by  the  agent, 
as  required  in  the  protocol  assumptions.  The  first  equation,  by  convention, 
names  the  principal  that  owns  the  agent,  so  that  the  role  of  the  agent  can 
be  determined.  Nonces  could  be  assigned  values  here  or  not,  depending  on 
the  needs  of  the  analysis  tool. 

When  several  environment  specifications  are  included  to  analyze  different 
scenarios,  each  one  can  import  previous  specifications  to  take  advantage  of 
the  constant  declarations  in  them.  Agent  declarations  are  not  imported. 

The  initial  knowledge  of  the  attacker  is  in  the  EXPOSED  section.  This  would 
normally  be  a  list  of  terms  that  the  attacker  is  assumed  to  hold  initially, 
possibly  including  some  items  that  are  declared  in  the  protocol  as  secret. 
The  attacker  may  be  implicitly  assumed  to  hold  agent  names. 

A  principal  with  an  EXPOSED  property  is  one  whose  private  data  is  all  held 
initially  by  the  attacker.  In  this  example,  if  Mallory  is  EXPOSED,  the  values 
of  private  functions  with  Mallory  as  the  first  argument  (such  as,  for  example, 
sk(Mallory))  would  not  have  to  be  added  to  the  EXPOSED  list,  because  they 
are  implicitly  assumed  to  be  exposed. 

Agents  are,  by  default,  assumed  to  run  concurrently.  CAPSL  permits  an 
ORDER  section  to  specify  some  series-parallel  sequencing  of  agents,  for  the 
benefit  of  search  tools  that  could  save  time  when  such  a  restriction  is  as¬ 
sumed.  For  example,  we  might  say:  ORDER  (Al;  A2)  |  |B1  to  mean  that 
agent  A2  does  not  start  until  Ai  ends,  but  that  sequence  runs  concurrently 
with  Bi. 

An  environment  specification  may  have  an  AXIOMS  section  for  assumptions 
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about  its  constants,  e.g.,  AXIOMS  sk (Alice)  =  SKa. 
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Chapter  3 

CIL 


3.1  Multiset  Rewrite  Rules 

Support  for  multiple  analysis  tools  is  accomplished  through  the  CAPSL 
Intermediate  Language  (CIL)  [DM99b].  The  purpose  of  CIL  is  to  unam¬ 
biguously  define  the  meaning  of  a  protocol  specification.  CIL  also  acts  as 
an  interface  through  which  protocols  specified  in  CAPSL  can  be  analyzed 
using  a  variety  of  tools. 

The  challenge  for  the  design  of  CIL  was  to  make  it  general  enough  and 
expressive  enough  to  represent  a  wide  range  of  protocols,  and  yet  at  a  low 
enough  level  to  be  close  to  the  representation  used  by  most  verification 
or  model-checking  tools.  Many  such  tools  share  a  specification  style  that 
incorporates  state-transition  rules  specified  in  a  pattern-matching  style,  with 
symbolic  terms  to  represent  encryption  and  other  computations.  There  is 
usually  a  separate  and  fairly  standard  intruder  model. 

As  an  example  of  the  use  of  pattern  matching,  if  there  is  a  message  B  ->  A ; 
B,  {Na,  Nb}PK(A),  we  infer  that  A  will  accept  only  messages  whose  second 
field  is  of  the  form  {Na,  Nb}PK(A).  This  implies  that  A  must  decrypt  the 
message  content  and  confirm  that  the  result  is  a  concatenation  of  two  fields 
of  type  Nonce.  Furthermore,  if  A  already  holds  a  value  for  Na  or  AT^,  it  will 
compare  that  with  the  one  in  the  message.  “Accepting”  a  message  means 
that  A  will  undergo  a  state  transition  as  a  result  of  receiving  it. 

The  commonality  in  the  abstract  symbolic  treatment  of  protocols  was  rec¬ 
ognized  and  codified  in  the  Cervesato,  et  al  meta-notation,  in  which  state 
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transitions  are  expressed  with  multiset  rewriting  (MSR)  rules  [CDL“*‘99]. 
The  MSR  notation  was  adapted  for  CIL.  Their  notation,  according  to  the 
authors,  could  be  regarded  as  either  an  extension  of  multiset  rewriting  with 
a  kind  of  existential  quantification,  or  a  Horn  fragment  of  linear  logic.  The 
simplicity  and  generality  of  this  formalism  made  it  suitable  to  serve  as  the 
language  in  which  to  express  the  semantics  of  CAPSL.  Furthermore,  the 
term-rewriting  aspect  corresponded  well  with  the  analysis  approach  taken 
by  Denker,  Meseguer,  and  Talcott  with  Maude  [DMT98b].  CIL  may  be 
regarded  as  a  notational  variant  of  the  MSR  formalism  in  which  certain 
specific  conventions  have  been  used  to  set  up  protocol  models  derived  from 
CAPSL  specifications. 


3.1.1  The  MSR  Protocol  Model 

The  MSR  formalism  uses  transition  rules  of  the  form 

Fi,...,Ffc  — >  (BXi,  ...,Xm)Gi, 

where  each  Fi  and  Gj  is  a  “fact.”  Facts  are  atomic  formulas  of  the  form 
P(ti, ...,  tr)  where  P  is  a  predicate  symbol  and  the  arguments  ti  are  terms.  A 
term  is  constructed  from  typed  constants,  variables,  and  function  symbols. 
Free  variables  are  implicitly  universally  quantified. 

The  state  of  a  system  can  be  represented  by  a  multiset  of  facts.  A  rule  is 
eligible  to  fire  when  the  facts  on  the  left  side  of  the  rule  can  be  matched 
with  facts  in  the  multiset.  When  a  rule  fires,  the  matching  facts  in  the 
multiset  are  removed  from  it  and  replaced  by  the  facts  on  the  right  side  of 
the  rule,  instantiated  according  to  the  substitution  required  by  the  pattern 
match.  Removing  a  fact  from  the  multiset  reduces  its  multiplicity  by  one,  if 
it  was  more  than  one.  Facts  in  the  multiset  are  typically  ground  terms  (no 
variables)  when  finite-state  search  tools  are  used. 

The  existential  quantifier  in  linear  logic  has  a  special  meaning.  Quantified 
variables  are  instantiated  with  fresh  (unused)  constants.  This  behavior  is 
used  to  model  generation  of  nonces. 

In  protocol  modeling,  facts  are  used  to  express  the  entrance  of  a  process  into 
a  state,  or  the  transmission  of  a  message.  In  MSR,  a  state  is  represented  by 
a  fact  Ai(...)  where  A  is  the  name  of  a  protocol  variable  of  type  Principal, 
z  is  a  state  label,  usually  an  integer,  and  the  arguments  are  the  “memory” 
of  the  agent  in  that  role  and  state.  A  message  (in  our  dialect)  is  a  fact 
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M{a,b,t)  where  a  and  b  are  principals  and  i  is  a  term  representing  the 
message  content.  Another  kind  of  fact  can  represent  attacker  knowledge. 

Rules  with  an  empty  left  side  are  interpreted  as  initialization  or  fact-gener¬ 
ating  rules.  For  each  role  in  the  protocol,  an  initial  state  fact  is  generated 
with  initially  held  variables.  The  rule 

—^AoiA,B),BoiB) 

creates  two  facts  representing  the  initial  state  of  two  new  agents.  Since  A 
and  B  are  variables  of  type  Principal,  this  rule  can  initiate  sessions  between 
any  pair  of  principals.  Thus,  Ao{A,B)  says  that  an  agent  playing  the  ‘A’ 
role  of  the  protocol  is  in  a  state  labeled  0  and  is  ready  to  begin  a  session 
between  principal  A,  which  owns  the  agent,  and  principal  B. 

The  message  A  ->  B:  A,  {N}SK (A)  would  result  in  at  least  two  transitions, 
one  for  the  sender  A  and  one  for  the  receiver  B.  The  A  transition  would  be: 

Ao{A,B)  {3N)A,iA,B,N),M{A,B,{A,{N}sT^{A)}). 

The  B  transition  would  be: 

Bo{B),M{X,B,{A,{N}s]^{A)})  BiiB,A,N). 

The  X  in  the  sender  position  of  the  received  message  is  a  new  variable. 
We  assume  here  (like  Paulson  [Pau98])  that  message  facts  indicate  the  true 
sender  of  the  message,  but  that  receiver  transitions  can  depend  only  on  the 
content  of  the  message,  and  therefore  the  sender  field  is  not  matched  with 
any  other  variable. 

3.1.2  CIL  Rule  Synteix 

MSR  rules  appearing  in  the  output  of  the  CAPSL  translator  are  expressed 
in  CIL  syntax,  in  a  uniform  functional  notation.  All  state  facts  are  of  the 
form  state(ro/e,  num,  terms(...)),  where  role  is  a  role  constant  constructed 
from  a  principal  variable  name,  such  as  roleA,  and  num  is  a  state  label, 
usually  a  natural  number.  The  memory  items  are  arguments  of  the  terms 
list.  Encryption  and  concatenation  are  expressed  using  the  functional  forms 
declared  in  the  prelude  or  other  typespecs.  Messages  are  msg  facts. 

So,  for  example,  the  transition 

Ao{A,B)  iBK)AiiA,B,K),M{A,B,{A}K) 
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would  appear  in  CIL  as 


rule (fact  s ( state (roleA , 0 , terms (A ,B) ) ) , 
ids(K), 

fact s (state (roleA , 1 , terms (A ,B ,K) ) , 
msg(A,B,terms(se(K,A))))) 

The  syntax  of  CIL,  which  includes  other  items  besides  rules,  is  given  in 
Appendix  A. 2. 


3.2  Translator  Overview 
3.2.1  CIL  Output 

The  translator  from  CAPSL  to  CIL  has  some  commonplace  tasks  to  per¬ 
form,  like  parsing  and  typechecking,  and  it  also  performs  the  conceptually 
challenging  task  of  unraveling  a  message-list  protocol  description  into  a  set 
of  rewrite  rules.  Besides  the  rules,  the  output  of  the  translator  includes  sym¬ 
bol  table  information  and  other  information  that  will  be  used  by  connectors 
and  analysis  tools. 

The  output  of  the  CIL  translation  has  several  parts: 

1.  slot  table 

2.  symbol  table 

3.  axioms 

4.  localized  assumptions 

5.  protocol  rewrite  rules 

6.  localized  goals 

7.  environment  information 

The  actual  output  of  the  CAPSL  translator  is  a  text  file  expressing  this 
information  in  the  abstract  syntax  of  CIL,  using  a  functional  notation.  A 
CIL  specification  has  the  form: 

CILspec( 

symbol s( symbol ( . 
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slots (slot (A, roleAjl) 
axioms  (...), 
assums(. . , 
rules ( 

rule(facts(. . .) ,ids(. . .) ,facts(. . , 


), 

goals (. . , 
envs (...), 

) 

The  CIL  specification  of  NSPK  can  be  found  in  Appendix  D. 

A  symbol  table  entry  has  the  form 

sjnA>ol{identjStatus,  arg-types^value-type, properties) 

where  ident  is  the  symbol  name,  status  is  the  kind  of  symbol,  one  of  op 
for  a  function  or  constant,  pvar  for  a  protocol  variable,  var  for  a  dummy 
variable,  or  type  for  a  type  name.  The  argument  types  are  in  a  list  of 
the  form  ids(...)  and  the  properties  are  in  a  list  of  the  form  props(...). 
The  symbol  table  contains  all  identifiers  declared  in  all  of  the  specification 
modules. 

The  slot  table  maps  each  protocol  variable  in  the  original  specification  to 
an  argument  position  in  the  state  predicate  of  each  role.  This  is  necessary 
for  interpreting  goals,  agent  initialization,  and  other  statements  that  refer 
to  protocol  variables. 

For  example,  if  we  assume  that  B  has  the  value  Bob  in  the  initial  state  of  an 
agent  in  role  ‘A’,  namely  state(roleA,0,  terms  (Alice,  Bob)),  we  need  to 
know  that  B  is  the  second  argument  in  the  terms  list  of  the  role  A  state  fact. 
This  is  expressed  by  the  slot  table  entry  slot  (B  ,roleA , 2) .  The  slot  number 
for  a  program  variable  does  not  change  once  it  is  created;  this  convention  is 
enforced  by  the  way  the  translator  generates  state  facts. 

Axioms  from  typespecs  and  environment  specifications  are  consolidated  into 
a  single  list. 

The  difference  between  axioms  and  assumptions  is  that  axioms  are  universal 
and  only  refer  to  dummy  variables,  while  assumptions,  like  goals,  refer  to 
program  variables  and  are  localized  to  particular  states.  Thus,  axioms  are 
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simply  passed  on  as  the  abstract-syntax  form  of  axioms  that  occur  in  the 
CAPSL  specification.  Assumptions  and  goals  are  expressed  in  the  form 
loc(nodes(node(roZe,  state)^  ...  ),  assertion). 

A  CAPSL  assumption  is  localized  to  the  initial  state,  and  a  typical  node 
would  be  node  (role A, 0).  Declarations  of  such  role  constants  are  added 
automatically  to  the  symbol  table.  CAPSL  goals  are  localized  to  the  final 
state,  as  determined  by  the  translator.  The  assertion  is  the  abstract-syntax 
form  of  the  CAPSL  assertion. 

The  CIL  format  for  rules  was  summarized  above,  and  the  process  for  gen¬ 
erating  them  is  discussed  in  detail  below  in  this  chapter. 

An  environment  entry  has  the  form 

environment (iden^,  agents(...),  exposed(...),  order(...)) 

where  the  exposed  and  order  components  may  be  empty,  and  an  agent  is 
specified  as  agent(iden^,  eqns(eqn(pi;ar,  term)^  ...)).  The  identifier  is  just 
a  reference  constant,  and  the  equations  assign  values  to  protocol  variables. 
The  first  protocol  variable  listed  is  the  principal  whose  variable  name  defines 
the  role  being  played  by  the  agent.  Other  protocol  variables  are  set  as 
required  to  provide  initial  values.  The  values  are  usually  given  as  constants 
declared  in  the  environment.  The  CIL  symbol  table  includes  those  constants. 


3.2.2  Translation  Stages 

The  major  stages  in  translation  are  the  following: 

1.  Parsing  and  type  checking 

2.  Syntax  transformations 

3.  Rule  generation 

4.  Local  Assertions 

5.  Optimization 

Parsing  checks  CAPSL  syntax  and  produces  a  parse  tree.  Type  checking 
confirms  the  consistency  of  type  and  signature  declarations  with  each  other 
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and  with  terms  occurring  in  axioms,  messages  and  elsewhere.  In  the  process, 
it  replaces  generic  encryption  expressed  with  bracketed  terms  by  a  choice  of 
ped  or  se  by  checking  the  type  of  the  key.  It  also  generates  a  symbol  table. 

There  are  several  syntax  transformations: 

1.  INCLUDE  phrases  are  expanded  by  replacing  them  by  the  message  list 
of  the  named  protocol. 

2.  Infix  arithmetic  operators  are  converted  to  functional  form. 

3.  cat  and  con  applications  are  made  binary  by  assuming  right  associa¬ 
tivity. 

4.  Uses  of  %  are  checked  and  lifted  to  the  top  level  of  each  term.  The 
function  symbol  for  %  is  lowe. 

5.  Role  constants  are  created  for  participating  principals. 

6.  DENOTES  equations  are  inserted  where  necessary.  This  is  covered  in 
more  detail  in  the  next  subsection. 

3.2.3  DENOTES  Processing 

The  idea  behind  DENOTES  processing  is  to  insert  an  equational  action  into 
the  message  list  when  a  variable  with  a  DENOTES  equation  is  seen  for  the  first 
time  by  each  principal.  These  modifications  are  made  in  abstract  syntax  to 
the  parse  tree,  rather  than  to  the  original  CAPSL  text. 

Suppose  that  the  specification  contains  DENOTES  X  =  fiX)  ' 

the  first  reference  to  X  by  A  is  in  an  action,  say  Z  =  g{X).  This  is  the 

simplest  case,  and  the  equation  for  X  is  placed  just  before  the  action. 

Even  in  this  simplest  case,  we  must  consider  that  Y  might  have  a  DENOTES 
definition,  and  its  use  will  recursively  require  the  insertion  of  its  equation, 
and  so  on.  This  concern  is  handled  by  (1)  requiring  that  DENOTES  equations 
be  placed  in  logical  order,  so  that,  in  this  case,  the  equation  for  Y  comes 
before  the  equation  for  X]  and  (2)  processing  the  DENOTES  equations  in  re¬ 
verse  order,  so  that  the  equation  for  Y  will  be  inserted  before  the  previously 
inserted  equation  for  X, 
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Suppose  the  first  reference  to  X  by  A  is  in  a  transmitted  message,  say  A  -> 
B:  Y,  X.  As  in  the  case  of  of  an  action,  we  place  the  equation  for  X  just 
before  the  message. 

Suppose  the  first  reference  to  X  by  A  is  in  a  received  message,  say  B  -> 
A:  Y,  X.  Then  we  cannot  place  the  equation  before  the  message,  because  it 
would  be  executed  by  B  rather  than  A. 

What  we  do,  instead,  is  (1)  replace  X  in  the  message  by  the  right  side  of  the 
equation,  /(F),  and  then  (2)  insert  the  equation  for  X  after  the  message. 
This  is  equivalent  to  having  written 

B  ->  A:  Y,  f(Y); 

X  =  f(Y); 

3.3  Abstract  Rule  Generation 

The  core  of  translating  CAPSL  to  CIL  is  the  creation  of  rewrite  rules  from 
messages  and  actions.  To  create  rules  successfully  for  a  message,  the  message 
must  be  implementable.  Two  issues  for  implementability  are  invertibility  and 
computablitity  of  message  fields. 

Each  message  gives  rise  to  at  least  two  transitions,  one  for  the  sender  and 
one  for  the  receiver.  With  respect  to  the  sender,  the  translator  must  check 
whether  the  sender  is  capable  of  computing  all  the  message  fields-that  is, 
whether  the  message  is  computable.  For  a  message  to  be  computable,  the 
sender  must  hold  the  variables  mentioned  in  it  and  be  able  to  access  any 
private  functions  used. 

With  respect  to  the  receiver,  the  translator  has  to  test  the  message  for 
”receivability.”  A  variable  is  receivable,  whether  it  is  already  held  or  not.  If 
it  is  held,  the  receiver  performs  a  comparison  with  the  prior  value.  If  it  is 
not  held,  it  is  learned,  and  a  slot  in  the  state  is  created  for  it.  In  the  case  of 
a  functional  term,  receivability  means  that  the  term  is  either  computable, 
so  that  the  receiver  can  compare  the  received  value  to  its  own  locally  stored 
or  recomputed  value,  or  it  is  invertible,  so  that  the  receiver  can  decompose 
it,  and  then  test  or  store  or  further  decompose  each  extracted  subterm. 

The  algorithm  for  generating  rules,  with  definitions  for  computability  and 
invertibility,  is  given  in  this  section.  For  purposes  of  presenting  the  algo¬ 
rithm,  we  regard  the  translator  as  a  finite-state  machine.  Its  state  is  a  set 
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of  role  states,  its  inputs  are  the  messages  in  the  message  list,  presented  in 
order,  and  its  outputs  are  the  generated  rules. 

3.3.1  Translator  State 

The  state  of  a  role  is  represented  by  a  term  5(p,n,x)  where  p  is  a  protocol 
variable  of  type  Principal,  n  is  a  state  number,  and  x  is  a  sequence  of  terms 
held  by  p.  Most  of  the  terms  in  x  are  protocol  variables,  but  compound 
terms  may  be  present  as  well. 

Before  any  message  is  processed,  the  initialization  rules  are  generated,  one 
for  each  role  in  the  protocol.  The  initial  role  state  for  p  has  n  —  0  and  a 
sequence  x  that  begins  with  p  and  also  includes  any  variables  declared  as 
held  by  that  principal  in  the  ASSUMPTIONS  declaration. 

For  our  purposes  in  describing  the  translation,  we  represent  a  message  as  a 
term  M (p,  g,  t%r)  where  p  and  q  are  the  variables  representing  the  sender 
and  receiver  of  the  message,  and  t%r  shows  the  sender’s  version  t  of  the 
message  content  and  the  receiver’s  version  r.  In  CAPSL,  a  message  can  have 
several  fields,  but  for  simplicity  we  assume  here  that  t  and  r  are  single  terms. 
If  the  message  has  more  than  one  field,  its  content  could  be  represented  as 
a  concatenation  of  these  fields. 

3.3.2  Computability  and  Receivability 

We  begin  with  some  necessary  terminology.  In  general,  a  boldface  symbol 
is  a  sequence,  so  x  =  for  some  n.  In  some  contexts  we  will  also 

use  X  to  refer  to  the  set  of  its  components.  R{p)  denotes  the  symbol  of  type 
Role  which  corresponds  to  a  symbol  p  of  type  Principal. 

Accessibility.  A  function  /(y)  is  p- accessible  if  /  is  not  private  (does  not 
have  the  PRIVATE  property)  or  /  is  private  and  yi  =  p. 

Computability.  In  defining  computability  of  a  term,  we  assume  that  some 
terms  are  held-this  is  the  set  G-and  we  derive  the  set  of  additional  variables 
X  that  are  needed  to  compute  the  term.  The  principal  p  is  mentioned  only 
because  of  the  need  to  test  accessibility. 

t  is  p- computable  given  G  with  X  if 
1.  t  E  G  and  X  =  0  or 
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2.  t  is  a  protocol  variable  and  t  ^  G  and  X  =  {t}  or 

3-  ^  =  /(y)?  /(y)  is  p-accessible,  each  yi  is  p-computable  given  G  with 

Xi,andX  =  Ui^i- 

We  say  that  t  is  p-computable  given  G  if  Hs  p^computable  given  G  with  0. 
If  Z  is  a  set  of  terms,  we  say  that  Z  is  p-computable  given  G  with 
if  each  t  e  Z  is  p-computable  given  G  with  At. 

As  an  example,  consider  t  ped(SK(A),  A"),  t  is  A-computable  given  {A} 
with  {AT}  because  ped  is  not  private,  and,  although  SK  is  private,  SK(A)  is 
A-accessible. 

Invert ibility.  To  define  p-invertibility,  we  assume  that  there  are  axioms 
of  the  form  inv(/(y),pi,  Z)  for  some  operators  /,  where  y  is  a  sequence  of 
different  variables  and  Z  is  a  list  of  terms  not  including  y^.  An  invertibility 
axiom  states  that  /(y)  can  be  inverted  to  compute  a  value  for  yt  provided 
that  the  values  of  all  terms  in  Z  are  computable.  For  example,  {X}pk(A)  can 
be  inverted  to  compute  the  value  for  X  given  sk(A).  The  CAPSL  concrete 
syntax  for  an  invertibility  axiom  uses  the  keyword  INVERT,  and  in  the  OIL 
syntax  this  becomes  an  invertible  statement.  Encyrption  functions  are 
generally  invertible;  look  at  the  prelude  for  examples  of  invertibility  axioms 
for  them. 

t  is  p-invertible  at  i  given  G  ift  =  /(y)  and  invert ible(/(y),2/i,  Z)  and  Z 
is  p-computable  given  G. 

Receivability.  If  a  term  i  is  a  variable  or  constant  (a  function  with  no 
arguments),  receiving  it  means  to  compare  it  with  the  terms  in  the  held  set 
G  and  add  it  to  G  if  it  is  not  there.  If  t  is  compound,  it  must  be  either 
computable  or  invertible,  and  in  the  latter  case  the  components  extracted 
from  it  are  received  recursively.  This  process  enlarges  G  to  H. 

t  is  p- receivable  given  G  to  Hii 

1.  t  is  p-computable  given  G  and  =  G,  or 

2.  t  is  p-computable  given  G  with  {t}  and  if  =  G  U  {t},  or 

3.  We  have: 

(a)  t  =  f{y)  is  p-invertible  at  some  j  given  G  and 
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(b)  y'  is  sequentially  p-receivable  given  G  to  where  y'  is  the 

maximum  subsequence  such  that  t  is  p-invertible  at  ij 

given  G,  and 

(c)  if  t  is  ^-computable  given  H'  then  H  —  else  H  =  \J  {t}. 

Sequential  receivability  expresses  the  notion  that  variables  learned  while 
receiving  a  message  can  be  used  to  compute  terms  received  later  in  the 
same  message. 

y  =  is  sequentially  p-receivable  given  G  to  .ff  if,  for  j  =  yj 

is  p-receivable  given  Gj  to  where  Gj  =  Hj-i  and  Hq  =  G  and  Hn  =  H. 

The  success  or  failure  of  the  sequential  receivability  test  depends  on  the 
order  of  the  sequence  of  terms,  since  the  held  set  G  is  augmented  as  part 
of  the  process.  A  more  forgiving  definition  would  be  able  to  rearrange  the 
order  to  find  one  that  works,  and  it  could  be  implemented  by  making  several 
passes  over  the  sequence. 

As  an  example,  consider  t  :=  ped(sk(A),  A'),  t  is  B-receivable  given  {A}  to 
{A,  i}.  Upon  receiving  t  the  agent  in  role  B  not  only  learns  the  nonce  N 

but  also  the  whole  term  t  since  t  is  not  ^-computable  given  {A,  A^}. 

3.3.3  Message  Rules 

A  message  M{p,q^t%r)  gives  rise  to  two  protocol  rewrite  rules,  one  for  p 
to  send  the  message  and  one  for  q  to  receive  r.  Each  protocol  rewrite 
rule  is  generated  by  a  translator  state  transition.  A  transition  associated 
with  sending  the  message  affects  only  the  sender-role  state,  and  the  one 
associated  with  receiving  the  message  alffects  only  the  receiver-role  state. 

A  schema  is  a  way  of  presenting  a  set  of  translator  transitions  in  a  parame¬ 
terized  form,  independent  of  the  particular  state  number  and  term  sequence. 
There  is  a  Send  schema  for  the  sender-role  transition  and  a  Receive  schema 
for  the  receiver-role  transition.  A  schema  may  specify  conditions  on  the 
state  transition;  if  they  are  not  satisfied,  the  transition  fails,  and  so  does  the 
translation.  A  schema  ends  with  a  protocol  rewrite  rule. 

The  Send  schema  says  that  if  the  message  is  computable,  possibly  with  a 
set  of  new  variables,  the  sender  can  transmit  the  message.  The  sender  must 
also  hold  the  identity  of  the  receiver. 
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Notation.  If  A  is  a  set  of  variables,  A  consists  of  the  elements  of  A  written 
as  a  sequence,  in  some  arbitrary  but  consistently  chosen  order. 

In  the  schemas  below,  a  variable  t  is  called  new  in  the  current  translator 
state  if  t  is  a  protocol  variable,  t  is  of  type  Nonce  or  has  the  FRESH  property, 
and  no  other  principal  q  has  t  in  its  current  state.  A  set  of  new  variables  is 
also  called  new. 

Send  schema: 

Current  state:  5(p,  n,x) 

Message:  M(p,^,t%r) 

Condition:  g  €  x  and  t  is  p-computable  given  x  with  A  and  A  is 
new 

Next  state:  5(p,n  +  l,xA) 

Rule:  5(iZ(p),n,x)  — >  (3A),5(i?(p),n  +  l,xA),M(p,  g,t) 

The  Receive  schema  says  that  if  the  message  content  is  receivable  with 
learned  terms  A,  the  receiver  accepts  the  message  and  adds  the  terms  in 
A  to  its  state. 

Receive  schema: 

Current  state:  5(g,n,  x) 

Message:  M{p^q^t%r) 

Condition:  r  is  g-receivable  given  xtoH  and  A  =  H  —  x 
Next  state:  S{q,n  +  1,  xA) 

Rule:  5(ii(g),n,x),M({7,g,r)  — >  S'(ii(g),n  +  l,xA) 

The  receiver  of  a  message  cannot  see  the  sender’s  address.  Thus,  we  assume 
an  arbitrary  sender  variable  U  of  type  Principal. 

Example.  Given  the  translator  state  S{B^  2,  [5,  A])  and  the  message  M{A^  B, 
{A}sk(A)),  the  new  translator  state  is  5(B,  3,  [J5,  A,  AT,  {Ar}sk(A)])  and  the 
following  GIL  rule  is  generated  to  receive  the  message: 

rule (facts (state (roleB , 2 , terms (B , A) ) , 

msg(Z,B,terms(ped(sk(A) ,N)))) , 

idsO  , 

facts(state(roleB,3,terms(B,A,N,ped(sk(A) ,N))))) . 


3.3.4  Equational  Actions 


The  right  side  of  an  equational  action  is  always  tested  for  computability. 
Depending  on  the  computability  of  the  left  side,  the  action  is  understood  to 
be  an  assignment  or  a  test  for  equality.  If  the  left  side  terms  are  con  or  cat, 
we  handle  them  in  a  particular  way. 

The  Test  schema  says  that  if  both  sides  of  the  action  are  computable,  then 
the  receiver  performs  a  test.  Two  rules  are  created  for  this  purpose.  In 
the  first  transition  the  equation  is  added  to  the  list  of  terms.  If  the  test  is 
evaluated  to  true,  then  the  second  transition  advances  the  state  number  and 
deletes  the  equation. 

Action  schema  (test): 

Current  state:  5(p,  n,x) 

Action:  t  =  t' 

Condition:  t  and  t'  are  p-computable  given  x 
Next  state:  S{p^  n  +  2,  x) 

Rules:  5(/?(p), n,x)  — >  S{R{p)^n-\-  l,x(t  =  t')) 

5(i?(p),  n  +  1,  true)  — ^  5(i?(p),  n  +  2,  x) 


The  Assignment  schema  requires  that  the  right  side  is  computable  and  that 
the  left  side  is  a  protocol  variable  that  is  not  held  by  the  agent.  Then  the 
agent  can  perform  an  assignment  transition. 

Action  schema  (assignment): 

Current  state:  5(p,  n,x) 

Action:  y  =  f 

Condition:  t'  is  p-computable  given  x  and  y  is  a  protocol  vari¬ 
able,  2/  ^  X 

Next  state:  5(p,  n  H- 1,  xy) 

Rule:  5(i?(p),n,x)  — >  S{R{p)^n-\-l^id!) 


If  the  left  hand  of  the  action  is  a  variable  that  is  not  held  by  the  acting 
agent,  then  the  action  is  an  assignment.  The  newly  assigned  term  is  added 
to  the  termlist  and  there  is  an  associated  slot  table  entry  that  relates  the 
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term  to  the  variable  y.  Consequently,  the  next  rule,  if  any,  refers  to  the  term 
as  variable  y. 

There  are  two  special  action  schemas  in  case  the  outmost  function  on  the  left 
side  is  one  of  the  two  concatenation  functions.  If  the  left  side  of  the  equality 
is  a  term  using  cat  or  con,  then  the  action  is  split  into  two  equalities,  one 
for  each  component  of  the  concatenation. 

Action  schema  (con): 

Current  state:  5(p,n,x) 

Action:  con{y,  z)  =t' 

Condition:  t^  is  p-computable  given  x 
Rules:  <  rules  for  y  =  head{t')  > 

<  rules  for  2:  =  tail{t*)  > 


Action  schema  (cat): 

Current  state:  5(p,  n,  x) 

Action:  cat(y,  z)  = 

Condition:  t^  is  p-computable  given  x  and  y  is  atomic 
Rules:  <  rules  for  y  =  first{t^)  > 

<  rules  for  z  =  rest{f)  > 


The  schema  for  cat  is  more  restrictive  since  the  first  operator  on  cat  is 
only  defined  if  the  first  argument  is  an  atom. 

3.3,5  Subprotocols 

The  schema  for  selection  says  that  the  agent  first  has  to  evaluate  the  con¬ 
dition.  If  the  condition  is  true,  it  transitions  into  a  new  state  that  is  the 
starting  state  for  all  rules  generated  for  the  subprotocol  Pi.  If  there  are  k 
transitions  for  p  in  subprotocol  Pi,  then  the  p  starts  from  state  n  +  A;  +  3  in 
the  branch  in  which  the  condition  did  not  hold  true. 


Selection  schema: 

Current  state:  S(p,  n,x) 
Phrase:  if  t  then  Pi  else  P2 
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Rules:  S{R(p),n,x.)  — >  S{R{p),n  +  l,x(<  =  true)) 

S{R{p),n+  l,x.true)  — >  S{R{p),n  +  2,x) 

S(R(p), n  +  1, xfalse)  — >  S{R(p),  n  +  3  +  A:, x) 

<  rules  from  Pi;  p  starts  from  n  +  2;  p  has  k  transitions  > 

<  rules  from  P2;  p  starts  from  n  +  3  +  A;  > 


States  of  other  agents  in  the  protocol  may  be  changed  in  the  invoked  sub¬ 
protocols.  Thus,  the  next  states  of  other  agents  have  to  be  also  reflected 
accordingly  in  the  branches  of  the  selection. 


3.4  Local  Assertions 

When  initial  conditions,  messages  and  actions  are  converted  to  state  transi¬ 
tion  rules  and  assertions  are  moved  into  a  separate  list,  the  temporal  inter¬ 
leaving  of  intermediate  goals  or  idealization  assumptions  with  the  message 
list  must  be  replaced  by  a  different  kind  of  interleaving,  which  associates 
them  with  network  states.  A  network  state  is  represented  with  a  list  of  roles 
and  state  labels. 

For  the  sake  of  uniformity,  initial  assumptions  are  localized  to  the  network 
state  in  which  all  roles  are  at  state  zero.  Assertions  in  the  GOALS  section  are 
localized  to  the  network  state  in  which  all  roles  are  in  the  last  states  produced 
by  the  rule  generation  process.  (Or  all  such  last  states,  if  branching  occurs.) 

A  local  assertion  is  of  the  (abstract)  form 
loc{node  sequence,  assertion) 
where  nodes  have  the  following  (abstract)  syntax: 
node(roZe,  state-label) 


3.5  An  Attacker  Model 

The  CAPSL  translator  does  not  generate  attacker  rules,  because  most  at¬ 
tacker  rules  would  be  standard  and  built  into  any  analysis  tool  that  needs 
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them.  A  standard  attacker  model  would  include  an  attacker  memory  fact 
such  as  N{u)^  meaning  that  the  attacker  holds  the  term  u.  Because  the 
attacker  can  intercept  any  message,  there  could  be  a  rule  M(A,  B,r)  — > 
N{T)  and  a  similar  rule  for  forging  messages,  N{T)  — >  N{T)^M{A,B,T). 
There  would  be  rules  for  decomposing  and  synthesizing  messages  using  the 
available  concatenation  and  encryption  functions.  A  general  attacker  model 
of  this  kind  is  described  in  [CDL“^99]. 

The  attacker  should  be  able  to  compute  the  value  of  any  function  declared 
in  a  typespec,  given  its  arguments,  except  private  functions.  If  there  is  a 
standard  (“Spy”)  or  declared  dishonest  principal,  the  attacker  can  compute 
that  principal’s  private  values,  e.g.,  sk(Spy).  The  attacker  can  compute 
constants,  since  they  are  simply  functions  with  no  arguments. 

Connectors  should  generate  certain  protocol-specific  or  scenario-specific  rules 
for  initializing  the  attacker,  using  information  from  the  environment  speci¬ 
fication. 

Initially  the  attacker  holds  all  exposed  terms  as  declared  in  the  environment 
section.  For  instance,  in  the  environment  used  as  an  example  in  Section  2.5, 
the  exposed  term  {Bob}sk(Alice)  results  in  a  fact-generating  rule  for  the 
attacker,  in  CIL  syntax: 

rule (facts  0 ,ids() , facts (net (ped(sk (Alice) ,Bob)))) , 
where  net(...)  is  the  CIL  version  N{.„)  above. 

If  a  principal  is  exposed,  then  all  private  functions  defined  for  this  principal 
are  also  exposed.  If  Mallory  is  a  PKUser,  there  would  be  a  rule 

rule (f  act  s ( ) , ids ( ) , f  acts (net ( sk (Mallory) ) ) ) , 

for  example. 

Since  all  constants  are  computable  by  the  attacker,  there  would  be  rules  like 
rule (facts 0 ,ids() , facts (net (Alice))) 

for  all  principal  constants  named  in  the  environment. 

For  purposes  of  inductive  proof,  it  is  simpler  to  assume  that  all  principals 
are  held  by  the  attacker,  with  a  rule 
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rule(facts() ,ids() , facts (net (A))) 

where  ^  is  a  variable  of  type  Principal.  On  the  other  hand,  inductive  proofs 
might  model  the  attacker  in  a  way  that  is  equivalent  to  a  rule  model  but 
expressed  quite  differently,  using  Paulson’s  Analz  and  other  set  closure  func¬ 
tions  [Pau98,  MROO]. 

An  environment  might  declare  constants  that  are  supposed  to  be  secret, 
such  as  nonces,  session  keys,  and  perhaps  symbols  defined  to  name  long¬ 
term  secret  keys  using  axioms.  These  constants  can  be  declared  with  the 
CRYPTO  property  to  prevent  them  from  being  given  to  the  attacker  initially. 

A  protocol  might  include  variables  representing  nonces  that  are  not  secret, 
such  as  sequence  numbers,  or  weak  passwords.  If  these  values  are  not  pro¬ 
tected  in  messages,  the  attacker  will  obtain  them  by  eavesdropping,  but  if 
they  are  protected  by  encryption,  there  will  need  to  be  further  attacker  rules 
stating  that  they  can  be  produced  by  the  attacker,  to  represent  guessing  or 
routine  computations. 
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Chapter  4 

Optimization  of  CIL  Rewrite 
Rules 


4.1  Motivation 


The  basic,  natural  translation  from  CAPSL  to  CIL,  as  described  Chapter  3 
and  [DM99a],  generates  two  rewrite  rules  per  message,  one  for  the  message 
sender  and  one  for  the  message  receiver.  Often,  however,  the  transition 
that  receives  a  message  and  the  one  from  the  same  agent  that  sends  a  reply 
can  be  collapsed  into  a  single  transition  that  does  both,  and  MSR  protocol 
encodings  produced  by  hand  usually  have  this  characteristic.  Successive 
computations  by  the  same  agent  to  update  or  enlarge  its  state  memory  can 
also  be  combined. 

The  optimization  algorithm  described  in  this  chapter  automatically  imple¬ 
ments  the  kind  of  rule  combinations  that  would  typically  be  done  by  hand. 
Relative  to  the  simple  message-by-message  translation,  this  reduces  the 
number  of  rules,  as  well  as  the  number  of  states  per  role,  by  about  50%.  We 
show  that  this  reduction  is  sound  in  the  sense  that  it  is  attack-preserving, 
by  essentially  the  same  definition  used  in  [SS98].  The  optimizing  trans¬ 
formation  has  been  implemented  as  a  post-processing  step  in  the  CAPSL 
translator. 

The  number  of  rules  has  direct  impact  on  the  performance  of  state  evalua¬ 
tion  tools  such  as  model  checkers.  In  the  model-checking  approach,  a  finite 
instantiation  of  the  protocol  is  tested  for  security  breaches.  For  this  purpose. 


45 


an  exhaustive  search  strategy  enumerates  all  reachable  states  for  a  given  ini¬ 
tial  state  and  tests  whether  they  invalidate  a  given  security  property.  Even 
for  small  protocols  and  very  restricted  numbers  of  sessions  the  number  of 
states  explodes.  This  is  due  partly  to  the  fact  that  the  intruder  behavior 
is  highly  non-deterministic,  and  partly  due  to  the  fact  that  new  sessions 
involving  legitimate  principals  may  be  created  and  execute  asynchronously. 
Thus,  a  linear  reduction  in  the  number  of  rules  can  reduce  the  number  of 
states  to  be  explored  by  an  exponential  factor. 

Because  optimizations  are  performed  as  a  series  of  successive  rule-combina¬ 
tion  steps,  there  is  a  question  as  to  whether  the  order  of  combination  steps 
aflfects  the  size  of  the  final  set  of  rules.  We  show  that  the  optimization, 
considered  as  a  reduction  system,  is  terminating  and  confluent,  and  hence 
canonical,  so  that  the  final  set  of  rules  is  unique. 


4.2  Optimization  Examples 

We  illustrate  the  optimization  steps  with  the  help  of  the  NSPK  protocol 
given  in  Section  2.1.6.  The  following  two  rewrite  rules  represent  receipt 
of  the  first  message  and  j5’s  sending  of  the  second  message  of  NSPK. 

rulel  :  Bo{B)  M{X,B,{Na,A}pk(B))  ^  B,{B,Na,A) 
rule2  :  Bi{B^Na^A)-^ 

{3Nt)  B2{B,Na,A,N,)  M{B,A,{Na,Nt}p,(A)) 

Under  the  assumption  that  agents  have  a  deterministic  behavior,  i.e.,  at 
most  one  rule  is  applicable  in  each  agent  state,  we  know  that  after  the 
receiving  the  message  from  A^  the  only  thing  B  can  do  is  to  reply  with  the 
second  message  to  A.  The  following  optimized  rule  combines  B^s  behavior 
into  a  one-step  transition  in  which  B  receives  ^’s  message  and  immediately 
replies  to  it: 

rulelj2  :  Bo{B)  M{X,Bj{Na^A}pk(B)) 

i3N,)  B2{B,Na,A,Nf,)  M{B,A,{Na,Nt}pk(A)) 

When  the  two  rules  are  combined,  the  original  pair  of  rules  is  deleted.  Op¬ 
timization  occurs  only  when  there  is  no  other  way  to  enter  state  Bi,  so  in 
efifect  state  Bi  is  also  eliminated. 
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Combining  the  rules  in  this  example  is  straightforward  since  the  right-hand 
side  of  the  first  rule  and  the  left-hand  side  of  the  second  rule  are  identical. 
More  generally,  for  two  rules  R  and  i?'  to  be  optimizable  it  is  necessary 
(though  not  sufficient)  that  the  state  fact  on  the  right-hand  side  of  R  is  an 
instantiation  of  the  state  fact  on  the  left-hand  side  of  i?'.  The  next  example 
illustrates  this. 

For  the  sake  of  this  example,  replace  the  message  B  ->  A:  {Na,Nb}pk(A) 
message  in  NSPK  by  a  sequence  of  two  actions,  an  assignment  and  a  message 
transmission,  so  that  the  message  list  is: 

MESSAGES 

A  ->  B:  {A,Na}pk(B); 

T  =  {Na,  Nb}; 

B  ->  A:  {Ty.{Na,Nb}}pk(A); 

A  “>  B:  fNb}pk(B); 

This  message  list  yields  the  following  CIL  rules  for  B  transitions. 

rulel  :  Bo{B)  ^ 

Tule2  :  Bi{B^Na^A) 

(aiVfc)  B2{B,Na,A,Ni,,{Na,Nk}) 

rule3:  B2{B,Na,A,Nt„T) 

B3{B,Na,A,Nt,T)  M{B,A,{T}pk(A)) 

In  this  case,  besides  combining  rulel  and  rule2,  we  can  also  combine  rule2 
and  ruled,  since  B2{B,  Na,  A,  Nb,  T)  can  be  instantiatiated  to  B2{B,  Na,  A,  Nb, 
{Na,  Nb})  with  the  substitution  T  {Na,  Nb}.  Thus,  we  can  optimize  these 

rules  to 

rule2,Z  :  Bi{B,Na,A) 

{3Nb)  Bi{B,Na,A,Nb,{Na,Nb}) 

M{B,A,{Na,Nb}^k(A))- 

Attack  Preservation.  In  order  to  assure  that  our  optimization  technique 
is  attack-preserving,  we  need  to  make  further  restrictions  on  the  form  of 
optimizable  rules.  For  a  pair  {R,  R')  of  rewrite  rules  to  be  combined,  we 
require  that  the  second  rule  has  no  messages  on  the  left-hand  side.  We 
show  with  the  help  of  a  simplified  example  that  allowing  a  message  on  the 
left-hand  side  of  the  second  rule  is  unsafe. 
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Assume  the  following  two  rewrite  rules  for  an  agent  in  role  B, 


rulel:  BoiB)  ^  Bi{B,B) 

rule2  :  Bi[B,B)  M\A,B,sk(B))  ^  B2{B,B) 

Since  the  state  predicate  Bi{B^  B)  occurs  in  both  rulel  and  rule2  one  might 
be  tempted  to  optimize  these  rules  to 

rulel,  2  :  Bo{B)  M{A,  B,  sk(B))  B2{B,  B). 

Assume  furthermore  that  M{A,B,  sk(B))  is  an  impossible  message,  because 
B  never  transmits  sk(B),  and  that  Bi  is  a  state  in  which  a  protocol  invariant 
fails,  perhaps  because  it  requires  that  the  first  two  components  of  B’s  state 
must  be  different.  Thus,  the  failure  state  is  reachable  in  the  original  protocol 
specification,  but  since  Bi  has  been  deleted  by  optimization  and  B2  cannot 
be  reached  since  M  is  impossible,  the  attack  state  is  no  longer  present  in 
the  optimized  protocol.  This  is  why  the  left-hand  side  of  the  second  rule  is 
not  allowed  to  have  messages. 

Name  clashes.  Before  we  can  formally  define  the  optimization  of  two 
rewrite  rules,  we  have  to  deal  with  variable  name  clashes.  In  order  to 
avoid  accidentally  introducing  bindings  between  variables,  we  apply  renam¬ 
ing  functions.  The  following  example  illustrates  the  need  for  renaming. 

Assume  the  following  two  rules  which  accidentally  use  the  same  variable  X : 

rulel  :  Bo{B)  M{X,B,A)  ^  Bi{B,A) 
rule2:  Bi{B,A)  {3X)  B2{B,A,X). 

These  rules  are  optimizable.  The  variable  X  is  used  in  both  rules,  though 
there  is  no  relation  between  the  variable  X  of  rulel  and  the  variable  X 
of  rule2.  To  avoid  introducing  a  binding  between  these  two  independent 
variables,  we  rename  X  of  rule2  to  X'  in  the  optimized  rule.  Thus,  the 
optimized  rule  for  rulel  and  rule2  is 

rulel, 2  :  Bo{B)M(X,B,A)  (3X')  B2{B,A,X^). 

The  coincidence  of  variables  B  and  A  in  the  two  rules  is  not  a  problem 
because  the  need  to  unify  the  Bi  facts  in  the  two  rules  determines  the 
appropriate  substitution  for  them. 
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4.3  Optimization  Steps 


As  intuitively  illustrated  in  the  previous  section  some  restrictions  on  rules 
are  necessary  to  guarantee  an  attack-preserving  optimization.  In  summary, 
we  only  consider  rules  that  describe  asynchronously  communicating,  deter¬ 
ministically  behaving  agents,  where  each  agent  state  is  generated  by  at  most 
one  rule. 

Local  rule.  For  optimizations  we  deal  only  with  local  rules,  in  which  only 
one  state  fact  appears  on  the  left  and  one  on  the  right  of  the  rule.  The 
rules  that  arise  from  protocol  transitions  in  an  asynchronous  environment 
are  normally  local,  since  only  one  agent  changes  state  at  a  time. 

A  rule  is  local  if  it  is  of  the  form 

i?  :  F  M  (3V)  F'  M' 

where  F,  F'  are  state  facts  for  the  same  role,  and  M  and  M'  contain  no 
state  facts.  Sets  of  variables  and  multisets  of  facts  are  denoted  in  bold-face 
letters. 

Deterministic  rule.  States  that  are  optimized  away  have  to  be  determin¬ 
istic  in  both  directions.  The  first  rule  of  an  optimized  pair  needs  a  backward 
deterministic  state  on  the  right,  while  the  second  rule  needs  a  forward  de¬ 
terministic  state  (the  same  state)  on  the  left. 

A  state  Ai  is  forward  deterministic  in  TZ  if  there  exists  at  most  one  rule  in 
TZ  with  a  fact  of  that  state  on  its  left-hand  side.  A  local  rule  is  forward 
deterministic  if  its  state  is  forward  deterministic. 

A  state  Ai  is  backward  deterministic  in  TZ  if  there  exists  at  most  one  rule  in 
TZ  with  a  fact  of  that  state  on  its  right-hand  side.  A  local  rule  is  backward 
deterministic  if  its  state  is  backward  deterministic. 

A  state  Ai  is  deterministic  in  TZ  if  it  is  both  forward  and  backward  deter¬ 
ministic. 

Optimizable  pair  of  rules.  In  the  following  definition  of  optimizable  pairs 
of  rules,  Vars{G)  is  the  set  of  variables  occuring  in  G, 

Given  a  pair  of  local  rules  (F,  B!)  in  TZ  of  the  form: 


F  :  F  Ml  ^  (3Vi)  G  M2 
F':  G' (3V2)  Ff  Ms 
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Then  the  pair  {R^R')  is  a-optimizable  if 


1.  R  and  are  local  on  the  same  role 

2.  There  are  no  variable  name  clashes  between  R  and  R' 

3.  There  exists  a  substitution  a  on  Var${G')  such  that  G'/a  =  G 

4.  The  state  of  which  G  is  a  fact  is  deterministic. 

As  mentioned  before,  name  clashes  have  to  be  resolved  before  our  optimiza¬ 
tion  technique  is  applied.  Name  clashes  can  always  easily  be  resolved  by 
renaming  variables.  In  section  4.5  we  describe  how  variable  renaming  can 
be  efficiently  realized  for  CIL. 

Optimization  step  and  optimized  rule.  We  now  can  present  the  defi¬ 
nition  of  the  optimized  rule  for  an  optimizable  pair  of  rules. 

Given  a  pair  (i?,  i?')  of  a-optimizable  protocol  rewrite  rules  of  the  form: 

iJ:FMi-^(3Vi)GM2 

i?'  :  G'  (3V2)  H  Ms 

then  an  optimization  step  removes  R^R  from  R  and  replaces  them  with 
R^  =  opt{R^R)^  defined  as 

R^:FMx^  (3Vi  V2)  M2  {H  Ms)lo. 


4.4  Properties  of  Optimization 

We  show  that  optimization  is  sound  in  the  sense  that  it  is  attack-preserving. 
We  also  show  that,  under  additional  assumptions,  it  delivers  a  unique  set  of 
optimized  rewrite  rules  regardless  of  the  order  in  which  optimization  steps 
are  applied.  Detailed  proofs  can  be  found  in  [DMKFGOO]. 

Protocol  Security  Invariants 

Before  we  go  into  the  details  of  the  proof,  we  make  some  observations  about 
protocol  properties.  Like  Shmatikov  and  Stern  [SS98],  we  only  deal  with 
protocol  security  properties  that  are  invariants;  that  is,  they  are  properties 
of  the  global  state  that  are  supposed  to  hold  for  all  reachable  states. 
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Furthermore,  the  invariants  depend  only  on  state  facts  and  intruder  memory, 
not  on  message  facts.  Secrecy  invariants  state  that  the  intruder  memory  does 
not  contain  certain  terms  (which  appear  in  the  state  memory  of  some  honest 
principal),  and  other  security  properties  such  as  agreements  and  precedence 
refer  only  to  state  facts.  As  pointed  out  in  [SS98],  if  a  security  invariant  is 
false,  it  remains  false  if  the  intruder’s  knowledge  increases.  They  called  this 
property  monotonicity  of  invariance. 

We  make  use  of  a  more  general  characterization  of  security  invariants.  In 
protocols  that  can  be  expressed  in  CAPSL  and  translated  to  CIL,  state 
memory  is  monotonic  for  honest  principals  as  well.  Once  an  honest  agent 
holds  a  value  for  a  protocol  variable  (associated  with  an  argument  position 
in  its  state  memory),  that  value  never  changes.  It  follows  that  invariants 
that  depend  only  on  the  global  state  cannot  change  their  truth  value  once 
the  relevant  variables  have  become  defined  for  a  given  agent.  In  particular, 
if  a  state  invalidates  a  protocol  invariant,  every  successor  state  will  violate 
this  invariant  as  well.  We  refer  to  this  property  as  persistence  of  violations. 

4.4.1  Soundness 

Our  soundness  argument  reasons  about  the  state  graph  (5,r)  of  a  rule  set. 
The  nodes  of  this  state  graph  are  the  possible  global  states  (multisets  of 
ground  facts)  S  of  the  protocol.  The  graph  has  directed,  labelled  transitions 
(edges)  T  consisting  of  pairs  of  states  related  by  the  instantiation  of  a  rule, 
which  labels  the  transition.  A  state  is  reachable  if  there  is  a  sequence  of 
transitions  to  it  from  the  empty  multiset,  which  is  the  initial  state.  We  will 
refer  to  a  state  graph  simply  by  its  transition  set  T,  since  one  can  find  all 
reachable  states  in  it. 

For  example,  the  transition  s  means  that  there  exists  a  rule  i?  :  F 
(3V)  G  and  a  substitution  a  such  that  F/a  is  a  subset  of  s  and  the  resulting 
system  state  s'  is  derived  from  s  by  replacing  the  multiset  of  ground  terms 
F/a  with  the  multiset  of  ground  terms  G/a.  (The  substitution  a  assigns 
unused  values  to  the  variables  in  V.) 

Optimization  steps  eliminate  two  rules  and  replace  them  with  a  new  com¬ 
bined  rule.  This  changes  the  state  graph  by  eliminating  those  transitions 
labelled  with  instantiations  of  the  eliminated  rules,  and  adding  new  transi¬ 
tions  made  possible  by  the  new  combined  rule.  The  new  state  graph  has  the 
same  set  of  states,  but  some  of  the  states  have  become  unreachable  because 
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some  local  states  have  been  optimized  away. 

Attack  preservation.  An  optimization  step  taking  T  to  T'  is  attack¬ 
preserving  if,  for  any  security  invariant  (/?,  and  any  state  s  reachable  in  T 
that  violates  there  is  a  state  s'  reachable  in  T'  that  also  violates  (p. 


Theorem  1  Optimization  steps  are  attack-preserving. 


In  the  proof  of  the  above  Theorem  we  make  use  of  a  lemma  that  shows 
that  a  transition  instantiating  the  second  rule  R'  of  an  optimizable  pair 
(jR,  i?')  commutes  with  any  other  transition  in  T.  The  basic  idea  is  to 
show  that  if  a  state  violating  a  security  invariant  is  reachable  with  a  path 
that  includes  transitions  due  to  one  or  both  of  the  rules  that  have  been 
eliminated  by  the  optimization  step,  then  that  state  is  reachable  using  an 
alternate  path  that  uses  the  new  rule  resulting  from  the  optimization.  The 
alternate  path  is  constructed  using  commutativity  properties  implied  by  the 
lemma.  Sometimes,  one  cannot  reach  the  original  violation  state,  but  then 
one  can  reach  another  state  reachable  from  the  violation  state,  which  must 
be  a  violation  state  by  the  persistence-of-violations  assumption. 


4.4.2  Termination  and  Uniqueness 

The  motivation  for  optimization  is  to  reduce  the  number  of  states  in  order 
to  speed  up  state  evaluation  tools  such  as  model  checkers.  Our  proposed 
optimization  technique  consists  of  single  optimization  steps  performed  in 
sequence.  For  analysis  tools  it  is  of  importance  whether  the  order  in  which 
optimization  steps  are  performed  has  an  impact  on  the  final  set  of  rules  or 
on  the  final  number  of  rules.  We  will  show  that  optimization  is  terminating 
and  delivers  a  unique  result. 

Optimization  can  be  understood  as  a  rewrite  system  in  which  a  set  of  rules  (a 
term)  is  rewritten  to  an  optimized  set  of  rules  (another  term).  A  well  known 
result  in  the  theory  of  rewrite  systems  says  that  a  term  has  a  unique  normal 
form  (i.e.,  it  cannot  be  further  rewritten  into  another  term)  if  the  rewrite 
system  is  canonical  (for  details  see  for  instance  [Sny91]).  For  a  rewrite 
system  to  be  canonical  it  has  to  be  noetherian  and  confluent.  Noetherian 
systems  have  no  infinite  sequences  of  rewrites.  A  rewrite  system  is  termed 
confluent  when  for  any  term  which  can  be  rewritten  into  two  different  terms 
via  several  rewrite  steps,  there  exists  a  common  reduction  term. 
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We  show  that  our  optimization  process,  understood  as  a  rewrite  system 
tranforming  between  sets  of  rules,  is  canonical.  That  means  that  optimiza¬ 
tion  is  a  terminating  process  which  delivers  a  unique  set  of  rules  as  result. 
Therefore,  speaking  in  terms  of  the  associated  state  graphs,  the  original 
state  graph  T  and  the  fully  optimized  state  graph  T',  we  can  infer  that  T'  is 
uniquely  determined.  For  practical  purposes  that  means  that  applying  the 
optimization  steps  proposed  in  this  paper  in  any  order  always  leads  to  the 
same  optimized  state  graph  which  can  be  used  for  security  analysis. 


Theorem  2  Given  a  state  graph  T,  then  there  exists  a  uniquely  determined 
fully  optimized  state  graph  T'. 

In  order  to  prove  termination  and  uniqueness  of  optimization  we  make  use 
of  two  lemmas.  The  first  one  states  that  a  rule  is  optimizable  with  at  most 
one  rule  to  the  right  (in  an  optimizable  pair)  and  at  most  one  rule  to  the 
left. 

Using  this  lemma,  we  can  argue  that  a  given  set  of  rules  can  be  arranged 
into  a  totally  ordered  list  of  rules  such  that  two  rules  are  optimizable  only  if 
they  are  adjacent  (but  adjacent  rules  do  not  necessarily  form  an  optimizable 
pair).  In  the  following  we  refer  to  such  a  list  as  list  of  optimizable  rules. 
We  show  that  optimization  steps  are  locally  confluent.  That  means  one  can 
always  reach  a  common  list  of  rules  after  two  optimization  steps  (generally, 
local  confluence  allows  for  more  than  two  rewrite  steps). 

The  second  lemma  is  concerned  with  local  confluence.  It  states  that  if  two 
optimization  steps  involve  different  optimizable  pairs  of  rules,  then  they  are 
commutative.  That  is,  they  might  be  executed  in  either  order  and  the  order 
has  no  effect  on  the  resulting  list  of  rules.  If  two  optimization  steps  have 
a  common  rule,  then  after  one  optimization  step  the  other  optimization 
step  is  no  longer  applicable  since  the  rule  which  both  steps  had  in  common 
has  been  deleted.  But  the  new  optimized  rule  can  be  taken  for  another 
optimization  step  to  yield  a  common  list  of  rules.  Moreover,  the  optimization 
relation  between  rules  is  preserved.  In  summary,  we  show  that  performing 
optimization  steps  on  a  list  of  optimizable  rules  satisfies  the  following  two 
conditions. 

1.  Performing  an  optimization  step  rewrites  a  list  of  optimizable  rules 
into  another  list  of  optimizable  rules.  Assume  in  the  original  list  the 
pair  (i?i,iZ2)  has  been  optimized  to  then  is  optimizable  to 
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the  left  with  whatever  rule  Ri  was  optimizable  to  the  left,  and  is 
optimizable  to  the  right  with  whatever  rule  R2  was  optimizable  to  the 
right. 

2.  Moreover,  we  show  that  optimization  steps  are  locally  confluent.  That 
is,  given  a  list  of  optimizable  rules  that  can  be  rewritten  into  two 
different  list  of  optimizable  rules,  we  can  always  perform  one  more 
optimization  step  in  order  to  reach  a  common  list  of  optimizable  rules. 

Since  the  set  of  rules  is  finite  and  each  optimization  step  reduces  the  number 
of  rules  by  one,  the  optimization  process  is  terminating.  Therefore,  the 
optimization  process  describes  a  rewrite  system  that  is  noetherian.  A  well 
known  result  in  the  theory  of  term  rewrite  system  says  that  a  system  is 
canonical  if  it  is  noetherian  and  confluent.  A  noetherian  system  is  confluent 
if  and  only  if  it  is  locally  confluent.  Thus,  using  the  local  confluence  Lemma 
concludes  the  proof  of  Theorem  2. 


4.5  Implementation 

A  CIL  rewrite-rule  optimizer  has  been  implemented  in  Java  and  is  applied  as 
a  post-processing  step  in  the  CAPSL-CIL  translator.  It  is  publicly  available 
together  with  the  CAPSL  parser,  type-checker  and  CAPSL-CIL  translator 
at  the  CAPSL  web  site  [MilOOb]. 

The  optimizer  starts  reading  a  CIL  specification  and  checks  pairs  of  rewrite 
rules  for  optimizability.  In  order  to  decide  whether  two  rules  are  optimiz¬ 
able,  the  optimizer  needs  to  access  information  from  the  CIL  specification. 
In  particular,  in  order  to  decide  whether  two  state  facts  are  optimization 
compatible,  the  types  of  symbols  are  checked.  This  way  we  can  guarantee 
that  a  proper  substitution  mapping  between  state  predicates  exists.  More¬ 
over,  the  optimizer  needs  to  access  assumptions  and  goals  in  order  to  check 
that  the  states  to  be  eliminated  are  not  named  in  goals  and  assumptions. 
As  long  as  two  optimizable  rules  are  found,  the  optimizer  computes  the  op¬ 
timized  rule,  deletes  the  original  rules  and  adds  the  new  optimized  one  to 
the  rule  set. 

Variable  Renaming.  In  previous  sections  we  mentioned  the  problem  of 
name  clashes.  The  simple-minded  solution  is  to  rename  all  variables  in  one 
of  the  rules  in  an  optimizable  pair  to  new  variables.  For  instance,  given  the 
optimizable  rules 
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rulel  :  M{X,B,A)  ^  {3X)Bi{B,A) 

rule2:  Bi{B,A)--^{3X)B2{B,A,X) 


we  could  rename  the  variables  B^  A^  and  X  of  rule2  using  the  renaming  map 

B^B',A^A\X^X^: 

rule2  :  A')  ^  (3X')  ^2(5',  A',  X') 

Now,  the  rules  do  not  have  any  variable  names  in  common  and  we  may 
optimize  them  obtaining 

rulel, 2  :  Bq{B)  M{X,B,A)  {3X')  B2{B,A,X'). 

As  one  can  observe,  some  of  the  renamed  variables  are  mapped  back  to 
their  original  name  due  to  the  given  substitution  map  a.  For  instance, 
in  the  example  above  B'  has  been  mapped  back  to  B  using  a.  Thus,  a 
more  efficient  solution  for  eliminating  name  clashes  is  to  only  rename  those 
variables  which  are  not  mapped  by  the  substitution  mapping  a. 

Let  {R,R^)  be  an  optimizable  pair  of  protocol  rewrite  rules 
R  :FMi^  (3Vi)  Pn{x)  M2 


and 

B'  :  Pn{y)  (3V2)  G  M3 

where  F,G,Pn{x),Pn{y)  are  state  facts,  x  =  xi.,.Xr,  y  =  2/1... 2/r,  and 
Ml,  M2,  M3  are  multisets  of  message  facts.  Let  W  and  W'  be  the  set  of 
variables  occurring  in  R  and  B'  respectively. 

The  optimum  of  B  and  R\  B^,  is  computed  by  the  following  algorithm: 

1.  E  =  {a:i  =  Ai  =  l,...,r} 

2.  C  =  {u|uGWAu€  W'  a  u  ^  E} 

3.  Mren  =  {u  u'  |  u  G  C  A  u'  ^  (W  U  W')} 

4.  Rren  “  B  fMren 

Let  Rren  =  Bn(y')  ^  G'  M^ 

5-  Msubst  ~  {2/^  ^  Xi  I  ^  A  i  —  1, . . . ,  r} 
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Q.  Ro-.P  Ml  (3Vi  V'2)  M2  (C  M's)/Msubst) 

7.  The  symbol  table  of  the  CIL  specification  is  updated  with  all  newly 
introduced  variables. 

C  represents  the  set  of  variables  which  may  cause  a  clash.  The  variables  in 
C  are  renamed  in  JR'  with  new  variables  using  the  renaming  map  Mren-  The 
optimum  is  now  computed  using  the  new  rule  Rren-  At  last,  new  variables 
are  introduced  in  the  symbol  table. 

We  have  applied  the  optimizer  to  several  protocol  specifications.  The  CAPSL 
specifications  of  the  protocols  may  be  found  at  our  web  site  [MilOOb].  The 
CIL  specifications  were  generated  using  the  publicly  available  CAPSL-CIL 
translator.  Table  4.1  shows  the  results.  The  reduction  ratios  clearly  show 


Protocol 

^  Input  Rules 

^  Output  Rules 

Reduction  Ratio 

NSPK 

7 

5 

28.57% 

EKE 

14 

6 

57.14% 

Otway 

9 

6 

33.33% 

WMF 

5 

4 

20% 

SRP 

19 

8 

57.89% 

SSL 

29 

11 

62.07% 

Voucher 

10 

5 

50% 

Table  4.1:  Reduction  ratio  of  CIL  rules 


that  the  optimizer  may  reduce  the  number  of  rules  significantly.  This  way, 
the  performance  of  verification  tools,  such  as  finite-state  exploration  tools, 
can  be  drastically  increased. 
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Chapter  5 

Analysis  Tools 


Integration  of  CAPSL  with  protocol  analysis  tools  includes  two  principal 
activities:  development  of  connectors  for  interfaces  from  OIL  to  existing 
tools,  and  development  of  analysis  techniques  using  general-purpose  tools 
that  can  be  adapted  for  this  purpose.  In  particular,  PVS  can  be  applied  to 
construct  inductive  proofs  of  protocols,  and  Maude  can  be  used  as  a  model 
checker  with  a  suitable  meta-level  search  strategy. 

Connectors  are  being  written  to  integrate  CIL  with  a  variety  of  formal  se¬ 
curity  analysis  tools,  not  only  PVS  and  Maude,  but  also  Athena  [Son99, 
MilOOa],  In  this  section  we  describe  the  analysis  techniques  developed  for 
the  application  of  PVS  and  Maude.  Before  doing  so,  we  summarize  the 
common  features  of  the  connectors  developed  for  PVS,  Maude,  and  Athena. 


5.1  Connector  Design 


Each  connector  has  to  fulfill  the  following  two  characteristics: 

Syntactical  and  semantical  correctness.  One  has  to  decide  which  CIL 
pieces  are  necessary  for  the  translation  into  the  targeted  tool,  and 
how  they  are  translated.  The  resulting  specification  needs  to  meet 
all  syntactical  requirements  of  the  target  language  and  the  translation 
has  to  express  CIL  constructs  in  a  way  that  fits  with  the  semantics 
of  the  analysis  tool.  In  some  cases  CIL  constructs  can  be  translated 
in  a  straightforward  fashion  into  concepts  of  the  target  language,  in 
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other  cases  the  connector  translation  re-interprets  CIL  constructs  and 
expresses  them  via  appropriate  (combinations  of)  language  constructs 
of  the  target  language. 

Practicability,  Though  there  might  exists  an  obvious  translation  into  the 
language  of  the  analysis  tool,  the  resulting  specification  might  not  be 
in  a  format  that  supports  efficient  and  practical  analysis.  For  instance, 
executability,  non-determinism,  and  performance  aspects  of  the  trans¬ 
formed  specification  have  to  be  taken  into  consideration.  The  connec¬ 
tor  algorithm  might  need  to  perform  alterations  or  optimizations  in 
order  to  meet  these  criteria. 

In  order  to  accomplish  these  objective,  certain  issues  must  be  addressed: 

-  The  translation  strategy  for  transition  rules 

-  Initialization 

-  Type  and  function  limitations 

-  Goal  generation 

-  Software  engineering  considerations  for  expediting  connector  writing. 

The  translation  strategy  is  different  for  each  tool,  and  generally  it  is  not  too 
difficult,  due  to  the  functional  congruence  between  CIL  rules  and  most  tool 
transition  rules. 

Intialization  refers  to  the  transfer  of  protocol-specific  declarations  into  the 
language  of  the  analysis  tool,  as  well  as  the  generation  of  any  protocol- 
specific  attacker  rules. 

Tools  are  sometimes  limited  with  regard  to  the  set  of  datatypes  and  functions 
with  which  they  can  deal  effectively.  The  connector  must  resolve  incompati¬ 
bilities  between  the  tool’s  vocabulary  and  the  typespecs  provided  in  CAPSL 
by  the  prelude  and  the  user. 

The  CAPSL  translator  passes  goal  statements  on  almost  unchanged  to  the 
connector,  which  must  do  the  best  it  can  to  generate  tool-specific  versions 
of  those  goals. 

Given  that  we  have  written  three  connectors  and  expect  that  others  will  be 
written,  we  have  attempted  to  make  the  common  features  as  transferable 
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as  possible.  There  is  fairly  good  support  for  writing  connectors  in  Java. 
There  is  a  Java  class  to  parse  the  CIL  output  into  a  labelled  tree  structure, 
using  another  Java  class  defining  the  labelled  tree  type.  The  user-invoked 
connector  class  is  typically  a  short  standard  program  that  invokes  the  parser 
and  passes  the  parse  tree  to  a  workhorse  translator  class. 

The  parser  and  tree  class  can  be  re-used  as  is,  and  the  user-invoked  connector 
class  of  one  connector  is  only  a  few  lines  different  from  that  of  another.  The 
workhorse  translator  class  is,  of  course,  tool-dependent,  but  it  can  make  good 
use  of  the  tree-manipulating  functions  provided.  Programming  a  connector 
in  this  environment  is  much  like  LISP  programming. 


5.2  PVS 

The  PVS  specification  and  verification  environment  was  developed  at  SRI 
and  has  been  applied  to  many  different  design  problems  for  high-assurance 
hardware  and  software  [ORS92].  Our  approach  to  using  PVS  for  crypto¬ 
graphic  protocol  verification  began  with  Paulson’s  trace  model  [Pau98]. 
We  then  modified  and  further  developed  the  approach  to  work  with  a  state- 
based  model  which  is  more  compatible  with  the  one  built  into  CIL. 

While  the  summary  of  our  PVS  approach  in  this  section  is  intended  to 
be  readable  without  a  prior  background  in  the  application  of  PVS,  some 
experience  with  PVS  would  be  necessary  to  put  it  into  practice. 

While  the  protocol  modeling  approach  and  the  inductive  proof  technique 
apply  to  both  secrecy  and  authentication  goals,  the  main  emphasis  of  this 
section  lies  in  the  description  of  our  formalization  of  the  secrecy  theorem 
published  in  [MROO].  This  theorem  reduces  secrecy  proofs  for  protocols  to 
first-order  reasoning;  in  particular,  discharging  these  proof  obligations  does 
not  require  any  inductions.  The  trick  is  to  confine  the  inductions  to  general, 
protocol- independent  lemmas,  so  that  the  protocol-specific  part  of  the  proof 
is  minimized.  Moreover,  secrecy  protocols  are  modularized  in  the  sense  that 
there  are  separate  verification  conditions  for  each  protocol  rule. 

We  illustrate  the  encoding  of  specific  protocols  in  our  model  using  the 
Otway-Rees  protocol  [OR87].  We  do  not,  however,  go  into  details  of  proofs, 
since  they  are  mostly  straightforward  adaptations  of  the  ones  stated  in  [MROO] 

In  order  to  formulate  our  results,  we  borrow  the  notion  of  ideals  on  strand 
spaces  [THG98],  and  we  show  how  this  concept  is  useful  in  a  state  model 
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context  for  stating  and  proving  secrecy  invariants.  We  show  how  the  com¬ 
plement  of  an  ideal,  which  we  call  a  coideal^  serves  as  a  catalyst  to  apply 
Paulson’s  calculus-like  set  operators.  Our  protocol  model  is  also  unusual  in 
that  message  events  are  interspersed  with  “spell”  events  that  generate  the 
short-term  secrets  in  a  session  and  specify  which  principals  are  supposed  to 
share  them. 

Besides  proving  secrecy  results  of  standard  benchmark  protocols  like  the 
Otway-Rees  and  the  Needham-Schroeder  (public  key)  protocols,  our  meth¬ 
ods  have  been  applied  successfully  (by  B.  Dutertre  of  SRI  International)  in 
the  process  of  verifying  the  group  management  services  of  Enclaves  [Gon97]. 

5.2.1  Modeling 

The  modeling  task  begins  by  defining  the  primitive  data  types  that  may 
occur  as  message  fields:  agents,  keys,  and  nonces.  This  choice  of  primitive 
types  is  derived  from  Paulson’s  approach,  and  the  PVS  connector  has  to 
convert  CAPSL  types  into  these,  such  as  from  Principal  (and  all  subtypes) 
to  agent. 

These  sets  of  objects  belonging  to  these  primitive  data  types  are  assumed 
to  be  disjoint,  and  they  are  all  subtypes  (subsets)  of  the  field  type  field. 
They  are  modeled  as  abstract  datatypes  in  PVS. 

An  agent  is  either  an  ‘ordinary’  user,  a  dedicated  server  Srv,  or  the  sup¬ 
posedly  malicious  Spy.  Each  agent  A  has  some  long-term  keys:  a  public  key 
Pub  (A),  a  corresponding  private  key  Prv(A),  and  a  symmetric  key  Shr(A). 

Message  fields  are  divided  into  primitive  and  compound  fields.  The  primi¬ 
tive  fields  containing  agents,  nonces,  and  keys  are  constructed  as  Agent  (A) , 
Nonce  (N),  and  Key(K).  (The  PVS  conversion  mechanism  is  used  to  suppress 
these  injections  in  the  sequel.)  Compound  fields  are  constructed  by  concate¬ 
nation  or  encryption.  The  concatenation  of  X  and  Y  is  the  term  X  ++  Y.  The 
encryption  of  X  using  the  key  K  is  Encr(K,X),  regardless  of  the  type  of  key. 
The  possible  message  fields  are  elements  of  the  datatype  field. 

Agents  and  compound  fields  are  never  designated  as  secret  by  policy,  though 
some  compound  fields  may  have  to  be  protected  to  maintain  the  secrecy  of 
some  of  their  components.  Thus,  we  define  basic  fields  as  nonces  and  keys, 
which  are  the  kinds  of  primitive  fields  that  may  be  designated  as  secret 
according  to  policy.  The  PVS  definition  of  the  membership  predicate  basic? 
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is  shown  below. 


basic?:  set [field]  =  union(Nonce?,  Key?) 

As  a  notational  convention,  variables  A,  B  and  variants  always  stand  for 
agents;  K  and  variants  always  stand  for  keys;  and  N  and  variants  are  always 
nonces.  X,  Y  and  Z  are  arbitrary  fields. 

Each  key  K  has  an  inverse. 


inv(K):  key  = 

CASES  K  OF 

Pub(A):  Prv(A),  Prv(A) :  Pub(A), 
Shr(A):  Shr(A),  Ssk(A) :  Ssk(A) 
ENDCASES 


Thus,  both  Shr(A)  and  Ssk(A)  are  symmetric.  The  special  agent  Server  is 
assumed  to  hold  the  symmetric  (and  thus,  shared)  key  Shr  (A)  of  any  agent 

A. 

There  are  three  kinds  of  events:  messages,  spells,  and  state  events. 

event:  DATATYPE 
BEGIN 

Msg(Cont:  field):  Msg? 

Cast(Secrets:  set [(basic?)] ,  Cabal:  set [agent]):  Spell? 
State(Role:  nat.  Label:  nat,  Memory:  field):  State? 

END  event 


Messages  are  essentially  Paulson’s  Says  events,  and  the  content  of  a  message 
event  is  a  field.  We  do  not  need  to  refer  to  the  sender  and  receiver  of 
a  message.  A  spell  generates  certain  session-specific  primitive  fields  and 
designates  them  as  secret.  A  spell  is  an  event  Cast(S,  C),  where  S  is  a  set 
of  short-term  basic  fields  called  the  book^  and  C,  the  so-called  cabal,  is  a  set 
of  agents  who  are  permitted  to  share  the  secrets  in  S. 

As  a  notational  convention,  we  use  E  (and  variants)  to  denote  events,  while 
M  is  a  message  and  C  is  a  spell. 
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A  global  state  is  simply  a  collection  of  events.  Notationally,  variants  of  H  are 
global  states.  We  shall  see  later  that  states  reachable  by  a  protocol  contain 
messages  in  transit  and  local  states  of  agents  participating  in  the  protocol. 

global:  TYPE  =  set [event] 


We  extend  the  notion  of  a  content  to  global  states  in  the  natural  way.  Spells 
and  state  events  do  not  contribute  to  the  content.  Similarly,  the  secrets  of 
a  state  are  obtained  as  the  basic  fields  of  the  secrets  of  its  cast  events. 

sees(H)(X):  boolean  = 

EXISTS  (M:  (Msg?)):  member(M,H)  fe  Cont(M)  =  X 

secrets (H) (X) :  boolean  = 

EXISTS  (C:  (Spell?)): 

member(C,H)  &  basic?(X)  &  member (X, Secrets (C) ) 


5.2.2  Inductive  Relations 

The  fundamental  operations  on  sets  S  of  message  fields,  as  introduced  by 
Paulson,  are  Parts  (S),  Analz(S),  and  Synth (S). 

Briefly,  Parts  (S)  is  the  set  of  all  subfields  of  fields  in  the  set  S,  including 
components  of  concatenations  and  the  plaintext  of  encryptions  (but  not  the 
keys).  Note  that  if  member  (X,  Part  s({Y})),  then  X  is  a  subterm  of  Y,  in  the 
sense  of  [THG98],  written  X  <=  Y.  The  subterm  relation  is  a  partial  order. 

Analz(S)  is  the  subset  of  Parts  (S)  consisting  of  only  those  subfields  that 
are  accessible  to  an  attacker.  These  include  components  of  concatenations, 
and  the  plaintext  of  those  encryptions  where  the  inverse  key  is  in  Analz(S). 

Analz(S)(X):  INDUCTIVE  bool  = 

S(X) 

OR  (EXISTS  Y:  Analz(S)(X  ++  Y)) 

OR  (EXISTS  Y:  Analz(S)(Y  ++  X)) 

OR  (EXISTS  K:  Analz(S) (Encr (K,  X))  AND  Analz(S) (inv(K))) 

The  intruder  in  our  model  synthesizes  faked  messages  from  analyzable  parts 
of  a  set  of  available  fields.  This  motivates  the  definition  of  false  (S). 
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Fake(S):  set [field]  =  Synth(Analz(S) ) 

Fake^Parts:  LEMMA  Parts (Fake (S))  =  imion(Parts(S) ,  Fake(S)) 


5.2.3  Ideals  and  Coideals 

If  the  spy  ever  obtains  some  secret  field  X,  it  can  transmit  X  as  the  content 
of  a  message.  Thus,  our  secrecy  policy  is  that  if  the  message  with  content 
X  occurs  in  some  trace,  then  NOT  member (X,S),  where  S  is  a  set  of  basic 
secrets. 

The  invariant  that  we  will  actually  prove  is  that  NOT  member  (X ,  Ideal  (S) ) , 
where  Ideal (S)  is  the  ideal  generated  by  S:  the  smallest  set  of  fields  that 
includes  S  and  which  is  closed  under  concatenation  with  any  fields  and  under 
encryption  with  keys  whose  inverses  are  not  in  S.  Here,  Ideal  (S)  is  the  k- 
ideal  Ik[S]  from  [THG98]  where  k  is  the  set  of  keys  whose  inverses  are  not 
in  S. 

With  our  choice  of  A:,  the  ideal  is  defined  as  follows: 

IdeaKSXX):  INDUCTIVE  boolean  = 

S(X) 

OR  (EXISTS  Y,  Z:  X=Y++Z&  (Ideal (S)(Y)  OR  Ideal (S) (Z))) 

OR  (EXISTS  Y,  K:  X  =  Encr(K,  Y)  &  Ideal(S)(Y)  &  NOT  S(inv(K))) 

Under  the  assumption  that  any  term  not  in  the  ideal  may  be  already  com¬ 
promised,  it  is  necessary  to  protect  this  whole  ideal,  because  compromising 
any  element  of  the  ideal  effectively  compromises  some  element  of  S.  It  turns 
out  that  protecting  this  ideal  is  also  sufficient. 

The  complement  of  and  ideal,  which  we  call  a  coideal^  is  denoted  by  Coideal  (S) . 
This  defines  the  set  of  fields  that  are  public  with  respect  to  the  basic  secrets 
S,  i.e.,  fields  whose  release  would  not  compromise  any  secrets  in  S. 

The  property  that  makes  the  notion  of  “coideal”  worth  defining  is  that 
coideals  are  closed  under  attacker  analysis,  thereby  implying  that  protection 
of  the  ideal  is  sufficient. 

Analz_Closure :  LEMMA  Analz (Coideal (S))  =  Coideal (S) 
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Synth„Closure :  LEMMA  subset? (S , (basic?) )  => 

Synth (Coideal (S))  =  Coideal (S) 


5.2.4  Protocols  and  Secrecy 

A  protocol  specifies  which  messages  or  spells  can  be  added  to  a  global  state. 
A  secret  in  a  spell  book  must  be  unused  in  the  prior  state,  in  the  sense  that 
it  is  not  a  part  of  any  message  content  and  it  has  not  occurred  as  a  secret 
in  a  prior  spell. 

unused(H:  global) (X:  field):  boolean  = 

basic?(X)  &  NOT(Parts(sees(H))(X))  k  NOT(secrets(H) (X) ) 


A  protocol  rule  is  a  triple  consisting  of  a  pre-  and  a  post  set  of  events  and 
a  set  of  nonces.  Intuitively,  such  a  rule  is  applicable  in  some  global  state  H 
if  the  pre  events  are  a  subset  of  H  and  if  the  nonces  in  the  rule  are  unused 
in  H.  A  rule  fires  by  deleting  the  pre  events  from  the  state  and  adding  the 
post  events. 


rule:  TYPE  = 

[#  Pre :  set [event] , 

Nonces :  set [(basic?)] , 
Post:  set [event]  #] 


There  are  several  local  conditions  on  protocol  rules.  First,  there  is  at  most 
one  spell  in  the  post,  and  a  cast  and  a  message  event  may  not  occur  simul¬ 
taneously  in  the  post.  Second,  all  secrets  of  casts  in  the  post  must  be  subset 
of  the  rule  nonces.  Third,  regularity  states  that  whenever  a  longterm  key 
K  is  neither  in  the  parts  of  the  content  or  the  memory  of  the  pre  then  it  is 
also  not  in  the  parts  of  the  content  or  the  memory  of  the  post. 


single.spelKpost :  set  [event]):  boolean  = 

FORALL  (C,  Cl:  (Cast?),  E:  (Event?)): 

(member(C,  post)  k  member (Cl,  post)  =>  C  =  Cl) 

&  (member (C,  post)  &  member (E,  post)  =>  NOT  Msg?(E)) 
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fresh(Ns:  set [(basic?)] ,  post:  set [event]):  boolean  = 

FORALL  (C:  (Cast?)):  member (C, post)  =>  subset?(Secrets(C) ,Ns) 

regular(pre,  taul):  boolean  = 

FORALL (K:  longterm): 

(NOT(Parts(sees(pre)) (K))  &  N0T(Parts (memory (pre) ) (K))) 

=>  (NOT(Parts(sees(post)) (K)) 

&  NOKPcirts  (memory  (post ))  (K))) 

It  is  usually  straightforward  to  check  that  rules  of  a  specific  protocol  obey 
these  conditions.  Usually,  we  (mis)use  the  PVS  prover  to  automatically 
check  these  static  conditions. 

Rules  that  satisfies  the  conditions  above  are  collected  in  the  type  protocol. 

protrule(rl:  rule):  boolean  = 
single^spell (Post (rl) ) 

&  fresh(Nonces(rl) ,Post (rl)) 

&  regular(Pre(rl) ,Post(rl)) 

protocol:  TYPE  =  set [(protrule)] 

A  protocol  P  and  a  given  set  of  initial  knowledge  I  (of  the  spy),  a  global  I- 
extension  is  a  binary  relation  of  states.  This  relation  determines  a  transition 
system.  An  extension  is  either  honest,  i.e.  it  corresponds  to  a  move  by  a 
player  following  the  rules,  or  it  is  faked  by  the  spy.  As  usually,  the  spy  is 
reduced  to  add  only  messages  with  a  content  that  can  be  inferred  from  the 
content  of  the  current  state  and  the  initial  knowledge. 

honest(P:  protocol)  (H,  HI):  boolean  = 

EXISTS (rl:  (P)): 

subset? (Nonces (rl) ,  xmused(H) ) 

&  subset? (Pre (rl) ,  H) 

&  HI  =  union(Post (rl) ,  difference(H,  Prestates (rl))) 

faked:  set  [field]  )  (H,  HI):  boolean  = 

EXISTS(X:  (Fake(union(sees(H) ,  I)))):  HI  =  add (Msg (X) ,  H) 


65 


global_extension(P:  protocol,  I:  set [field] )  (H,  HI):  boolean 
=  honest(P)(H,  HI)  OR  fake(I)(H,  HI) 

We  need  some  further  concepts  before  stating  our  secrecy  theorem.  The 
basic  secrets  associated  with  a  spell  include  not  only  the  elements  of  the 
spell  book  but  also  the  long-term  secrets  of  the  agents  in  the  cabal. 

ltk(C:  (Cast?))(X:  field):  boolean  = 

Key?(X) 

k  longtenn(Val(X)) 

k  EXISTS (A:  agent):  Q(A)(Val(X))  k  Cabal (C) (A) 

basic_secrets(C) (X:  field):  boolean  = 

basic? (X)  AND  (Secrets (C) (X)  OR  ltk(C)(X)) 

A  spell  is  compatible  with  an  initial  knowledge  set  that  does  not  compromise 
its  associated  basic  secrets,  or  mention  the  short-term  secrets  in  its  book. 

compatibleCl:  set [field] ) (C:  (Cast?)):  boolean  = 
disjoint? (basic^secrets(C) ,  Parts(I)) 

The  set  of  reachable  states  H  is  defined  in  the  usual  way  using  a  least  fixed- 
point  definition. 


reachable (P,  I)(H):  INDUCTIVE  boolean  - 
empty? (H)  OR  (EXISTS  (G:  global): 

reachable (P ,  I) (G) 
k  global_extension(P,  I)(G,  H)) 


A  protocol  is  secure  with  respect  to  its  secrecy  policy  and  the  spy’s  ini¬ 
tial  knowledge  I  if  every  reachable  state  it  generates  is  secret-secure.  This 
property,  for  traces,  was  called  “discreet”  in  [MROO]. 

secret_secure(I :  set [field] ) (H:  global):  boolean  = 

FORALL  C:  compatible (I) (C)  k  H(C) 

=>  subset? (sees (H) ,  Coideal (basic^secrets (C) ) ) 
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The  secrecy  proof  for  a  protocol  has  a  protocol-independent  part  and  a 
protocol-dependent  part.  The  protocol-dependent  part  is  expressed  by  the 
occulhiess  property  defined  below.  It  says  that  if  the  prior  state  is  secret- 
secure,  the  next  message  event  generated  by  the  protocol  does  not  compro¬ 
mise  a  secret.  This  has  to  be  proved  individually  for  each  protocol.  This 
protocol  property  was  called  “discreet”  in  [MROO]. 

occult (P:  protocol):  boolean  = 

FORALL  (I:  set [field] ,  H:  global, 

C:  (Cast?),  rp:  (protrule)): 
reachable (P,  I)(H) 

&  secret_secure(I) (H) 

&  compatible (I) (C) 

&  H(C) 

&  subset? (Pre (rp) ,  H) 

&  P(rp) 

=>  subset? (sees (Post (rp)) ,Coideal(basic_secrets(C))) 

The  protocol-independent  part  of  a  secrecy  proof  is  the  Secrecy  theorem.  It 
only  has  to  be  proved  once. 

secrecy:  THEOREM 

occult(P)  =>  subset? (reachable (P,  I) ,  secret. secure (I) ) 

The  proof  of  this  theorem  is  along  the  lines  of  the  proof  in  [MROO]  for  proving 
a  secrecy  theorem  for  trace  models,  but  now  the  induction  is  on  the  length 
of  protocol  extensions. 

Notice  that  these  are  strictly  secrecy  results,  and  show  only  that  the  secrets 
generated  in  a  particular  run  of  the  protocol  are  not  compromised.  Most 
authors  of  protocol  proofs  have  noted  that  the  security  objectives  of  a  proto¬ 
col  may  be  undermined  in  other  ways  than  by  compromising  secrets,  usually 
due  to  some  failure  of  authentication.  Possible  combinations  of  secrecy  and 
authentication  are  discussed  in  [MROO]. 

5.2,5  Example:  The  Otway-Rees  Protocol 

The  goal  of  the  Otway-Rees  protocol  is  to  mutually  authenticate  an  initiator 
and  responder  and  to  distribute  a  session  key  generated  by  the  server.  The 
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protocol  consists  of  four  messages,  presented  below  as  they  appear  in  a 
CAPSL  MESSAGES  section. 

The  security  objective  is  to  prove  that  none  of  the  secrets  Na,  Nb,  or  K  are 
disclosed. 

orl.  A  ->  B:  M,A,B,{Na,M, A,B}KasyoFl  ; 

or2.  B  ">  Srv:  M, A,B,Fl7.{Na,M,A,B}Kas ,{Nb,M,A,B}Kbs ; 

or3.  Srv  ->  B:  M,{Na,Kab}Kasy.F2,{Nb,Kab}Kbs; 

or4.  B  ->  A:  M,F2y.{Na,Kab}Kas ; 

The  full  protocol  specification  includes  DENOTES  declarations  indicating  that 
Kas  and  Kbs  are  the  keys  shared  by  A  and  B,  respectively,  with  the  server 
Srv. 

The  PVS  encoding  of  this  protocol  shown  below  was  produced  by  hand.  The 
PVS  connector  produces  a  much  less  readable  version.  The  PVS  connector 
is  also,  as  of  this  writing,  not  yet  capable  of  producing  the  spells  and  proof 
obligations  automatically.  Here  we  only  state  a  selection  of  the  formalization 
of  the  Otway-Rees  protocol  rules. 

The  spell  rule  spll  generates  the  nonce  Na  as  needed  for  the  first  protocol 
step.  Note  that  the  server  need  not  be  mentioned  in  the  cabal. 

spll(A,  B:  agent,  Na:  nonce):  (protrule)  = 

(#  Pre  :=  emptyset, 

Nonces  :==  singleton  (Na)  , 

Post  :=  singleton(Cast(add(Na, emptyset) , 

add (A,  add(B,  emptyset)))) 

#) 

The  type  constraint  (protrule)  causes  the  PVS  type  checker  to  generate 
verification  conditions  corresponding  to  the  conditions  on  protocol  rules. 
These  and  all  the  other  verification  conditions  are  easily  discharged  using 
the  PVS  prover. 

Sending  and  receiving  is  split  into  two  parts.  The  first  step  in  the  Otway- 
Rees  protocol,  for  example,  is  transcribed  as  follows. 

sndl(A,  B:  agent,  N,  Na:  nonce):  (protrule)  = 
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(#  Pre 


:=  adcKState  (roleA ,  0,  A  ++  B  ++  Srv)  , 
add(Cast(add(Na,  emptyset), 
add(A,  add(B,  emptyset))),  emptyset)), 

Nonces  :=  add(N,  emptyset). 

Post  :=  add(State (roleA,  1,  A  ++  B  ++  Srv  ++  Na) , 
add (Msg (N  ++  A  ++  B  ++ 

Encr(Shr(A),  Na  ++  N  ++  A  ++  B)),  emptyset)) 

#) 

rcvl(A,  B:  agent,  N,  Na:  nonce):  (protrule)  = 

(#  Pre  :=  add (State (roleB,  0,  B  ++  Srv), 
singleton(Hsg(N  ++  A  ++  B 

++  Encr(Slir(A) ,  Na  ++  N  ++  A  ++  B)))), 
Nonces  :=  emptyset. 

Post  :=  singleton(State (roleB,  1,  B  ++  Srv  ++  N  ++  A)) 

#) 

Rules  that  introduce  nonces  (to  be  kept  secret)  take  them  from  a  prior  spell 
with  the  expected  cabal.  When  an  agent  uses  a  secret  from  a  spell  book,  the 
agent  does  not  see  any  of  the  other  secrets  in  the  same  spellbook,  though  it 
might  know  about  them  from  prior  messages. 

In  general,  a  sequence  of  states  generated  by  these  rules  interleaves  the 
behavior  of  as  many  agents  as  we  wish,  and  any  number  of  concmrrent  or 
sequential  sessions  of  the  same  agents.  Altogether,  the  Otway-Rees  protocol 
is  formalized  as  follows. 

otway_rees:  protocol  = 

{  r:  (protrule)  I 

EXISTS  A,  B,  N,  Na,  Nb,  K: 
r  =  init(A,  B) 

OR  r  =  splKA,  B,  Na) 

OR  r  =  sndl(A,  B,  N,  Na) 

OR  r  =  rcvKA,  B,  N,  Na) 

OR  ...} 

The  secrecy  theorem  states  that  it  suffices  to  show  occult  (otwayjrees).  In 
a  first  step,  using  skolemization  and  split  rules  in  order  to  show  occultness 
for  reach  rule  separately.  For  the  lemma  below  occultness  follows  trivially 
for  most  protocol  rules. 
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suf f icient^for^occultness :  LEMMA 

disjoint? (Msg?,  Post(rp))  =>  occult (singleton(rp)) 


It  remains  to  prove  occultness  for  four  rules  in  the  Otway-Rees  protocol.  In 
the  case  of  the  sndl  rule,  for  example,  one  has  to  prove: 

{“1}  subset? (sees (H) ,  Coideal (basic_secrets(C))) 

{-2}  reachable(OR,  I)(H) 

{-3}  H(C) 

{-4}  H (State (role A,  0,  A  ++  B  ++  Srv)) 

{”5}  H(Cast (add(Nonce(Na) ,  emptyset), 
add(A,  add(B,  emptyset)))) 

I - 

{1}  Coideal (basic^secrets (C) ) 

(N  ++  A  ++  B  ++  Encr(Shr(A),  Na  ++  N  ++  A  ++  B)) 

Currently,  we  still  prove  these  kinds  of  verification  conditions  in  an  inter¬ 
active  way  (typically  around  20-40  interactions  per  rule),  but  the  repetitive 
patterns  in  these  proofs  suggest  higher-level  proof  strategies. 

5.2.6  Conclusions 

Our  secrecy  theorem  separates  protocol-dependent  and  protocol-independent 
aspects  of  secrecy  proofs.  The  protocol-dependent  part  is  to  show  the  oc¬ 
cultness  property,  which  only  asks  whether  honest  messages  compromise 
secrets,  given  strong  assumptions  about  the  preservation  of  secrecy  in  the 
prior  message  history. 

The  secrets  to  be  protected  are  defined  in  an  explicit,  uniform  way  by  intro¬ 
ducing  “spell”  events  into  the  protocol.  Spell  events  generate  the  short-term 
secrets  for  a  particular  “cabal”,  the  set  of  agents  sharing  the  new  secrets. 
Secrets  are  shown  to  be  protected  even  when  the  long-term  secrets  of  other 
agents,  or  the  short-term  secrets  in  other  protocol  runs  (with  other  spells) 
are  compromised. 

The  closure  results  on  the  coideal  have  turned  out  to  be  a  useful  addition  to 
the  arsenal  of  proof  techniques,  enabling  interesting  examples  to  be  shown 
secure.  Protocol  proofs  are  still  complex  enough  so  that  we  feel  proof¬ 
checking  and  automation  to  be  valuable  for  the  sake  of  assurance,  and  we 
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believe  that  the  same  techniques  that  simplify  manual  proofs  will  also  be 
helpful  in  organizing  machine-assisted  proofs. 

Currently,  we  are  developing  high-level  PVS  strategies  for  automatically 
discharging  most  verification  conditions  for  typical  protocol  rules.  In  these 
strategies  we  try  to  capture  the  repetitive  patterns  that  have  been  showing 
up  in  hand  and  mechanized  interactive  proofs.  It  is  our  hope  that,  using 
these  strategies,  we  can  prove  secrecy  results  about  realistic  protocols  in 
a  fairly  automatic  way.  We  have  developed  an  initial  version  of  the  PVS 
connector,  but  it  needs  to  be  improved  to  create  more  readable  protocol 
theories  and  to  incorporate  goal  information. 


5.3  Maude 

In  this  section  we  describe  the  design  decisions  and  optimization  solutions 
for  a  CIL  connector  to  Maude.  Maude  is  a  novel,  wide-spectrum  executable 
formal  specification  language  that  has  been  successfully  applied  to  commu¬ 
nication  and  security  protocols  (see  case  studies  on  the  Maude  web  page 
[MauOO]).  In  particular,  Maude  can  be  efficiently  used  as  a  model  checker 
for  security  protocols  as  shown  in  [BDOO,  DMTOO,  DMT98b].  In  order  to 
minimize  translation  efforts  into  Maude  and  achieve  maximal  reusability  of 
search  strategies,  attacker  model  and  other  predefined  data  structures,  we 
designed  a  CIL-to-Maude  connector  that  has  been  implemented  in  Java. 
Such  a  connector  automatically  translates  CIL  specifications  into  Maude, 
and,  thus,  enables  a  protocol  designer  to  make  use  of  the  Maude  model 
checking  facilities  without  knowing  Maude  specifics.  The  following  is  a  list 
of  “ingredients”  for  the  CIL  connector  to  Maude: 

-  Specification  of  pre-defined  CAPSL  data  types  in  Maude; 

-  Representation  of  the  CIL  model  in  Maude; 

-  Definition  of  an  attacker  model; 

-  Algorithm  for  translating  protocol  specific  CIL  constructs  (such  mes¬ 
sage  lists  and  environments)  into  Maude; 

-  Definition  of  a  general  search  strategy  for  model  checking; 

-  Protocol-dependent  and  protocol-independent  optimization  techniques 
that  improve  the  performance  of  the  Maude  model  checker; 
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We  illustrate  the  design  of  the  CIL-to-Maude  connector  by  means  of  an 
example.  A  prototypical  implementation  of  the  Maude  connector  in  Java  is 
finished.  In  the  appendix  we  present  the  Maude  specification  that  has  been 
produced  using  the  connector. 

5,3.1  The  Maude  Language 

Maude  [CDE‘^99,  CELM96,  MauOO]  is  a  multi-paradigm  specification  lan¬ 
guage  based  on  rewriting  logic  [Mes92].  Maude  specifications  can  be  effi¬ 
ciently  executed  using  the  Maude  rewrite  engine,  thus  allowing  their  use  for 
system  prototyping  and  the  debugging  of  specifications. 

Part  of  what  makes  Maude  very  well  suited  for  the  purpose  of  protocol 
analysis  is  its  flexible  wide-spectrum  character:  it  can  deal  with  very  early 
design  phases  such  as  architectures  and  high-level  designs,  can  be  used  to 
quickly  develop  executable  prototypes,  and  can  also  be  used  to  generate 
code.  There  is  also  a  wide  range  of  options  on  the  kind  of  analyses  that 
can  be  performed.  One  can  develop  formal  models  of  a  system  very  early, 
can  debug  formal  specifications — which  can  be  partial  and  incomplete — 
by  executing  them,  can  do  more  exhaustive  model-checking  and  symbolic 
simulation  analyses,  or,  for  highly  critical  subsystems,  can  in  fact  do  full 
formal  verification  using  Maude’s  theorem  proving  tools. 

The  Maude  model  checker  makes  use  of  the  reflective  capabilities  of  rewriting 
logic  and  Maude  [CM96].  Reflection  allows  user-defined  execution  strategies 
that  can  be  formally  specified  by  rewrite  rules  at  the  metalevel,  including 
strategies  such  as  breadth-first-search  that  can  exhaustively  explore  all  the 
executions  of  a  system  from  a  given  initial  state. 

We  briefly  summarize  the  syntax  of  Maude.  In  the  CIL-to-Maude  connector 
we  mainly  make  use  of  the  following  two  types  of  modules: 

-  functional  modules,  that  are  equational  theories  used  to  specify  alge¬ 
braic  data  types;  they  are  declared  with  the  syntax  f mod  . .  .  endf m, 
and 

-  system  modules,  that  are  rewrite  theories  specifying  concurrent  sys¬ 
tems;  they  are  declared  with  the  syntax  mod  . . .  endm,  and 

Immediately  after  the  module’s  keyword,  the  name  of  the  module  is  given. 
After  this,  a  list  of  imported  submodules  can  be  added.  One  can  also  de- 
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dare  sorts  and  subsorts  (specifying  sort  inclusion)  and  operators.  Operators 
are  introduced  with  the  op  keyword.  They  are  declared  with  the  sorts  of 
their  arguments  and  result,  and  syntax  is  user  definable  using  underscores 
to  mark  the  argument  positions.  Some  operators  can  have  equational  at¬ 
tributes^  such  as  assoc  and  comm,  stating,  for  example,  that  the  operator  is 
associative  and  commutative.  Such  attributes  are  then  used  by  the  Maude 
engine  to  match  terms  modulo  the  declared  axioms. 

We  make  use  of  two  kinds  of  logical  axioms,  namely,  equations — introduced 
with  the  keywords  eq,  or,  for  conditional  equations,  ceq — and  rewrite  rules — 
introduced  with  the  keywords  rl,  or  for  conditional  rules  crl.  Functional 
modules  can  only  have  equations,  whereas  system  modules  can  have  any 
kind  of  axioms.  The  mathematical  variables  in  such  axioms  are  declared 
with  the  keywords  var  and  vars. 

5.3,2  Translation  of  the  CAPSL  Prelude 

Our  current  connector  is  restricted  to  the  operators  provided  in  the  CAPSL 
prelude  (i.e.,  list  concatenation,  cryptographic  operators  for  symmetric  and 
public  key  encryption,  etc.)  which  have  been  efficiently  translated  into 
Maude.  The  Maude  module  with  the  CAPSL  prelude  is  automatically 
loaded  with  any  CAPSL  protocol  specification. 

In  general  any  CAPSL  type  declaration  can  be  translated  into  Maude.  The 
reason  for  this  restriction  lies  in  the  attacker  model.  The  complexity  of  the 
attacker  model  is  proportional  to  the  number  of  function  declarations  and 
axioms.  The  more  operators  are  defined,  the  more  possible  computations 
an  attacker  can  perform.  We  restricted  our  attacker  model  to  the  usual 
functionality  of  composing  and  decomposing  as  well  as  encrypting  and  de¬ 
crypting  messages  using  the  standard  operators  defined  in  the  prelude  (e.g., 
cat  ,con,ped,se).  As  a  consequence,  we  only  deal  with  type  specifications 
from  the  CAPSL  prelude. 

Type,  function,  and  constant  declarations.  Type  and  subtype  decla¬ 
rations  correspond  to  sort  and  subsort  declarations  in  Maude.  For 
instance,  the  declaration  TYPES  Role,  Spec,  Agent:  Object  trans¬ 
lates  into  the  Maude  sort  declarations 

sorts  Object  Role  Spec  Agent  . 

and  additional  subsort  declarations 
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subsorts  Role  Spec  Agent  <  Object  . 


Since  there  exists  no  default  supersort  in  Maude  we  have  to  explicitly 
define  subsort  relationship  for  all  subtypes  of  Atom.  Functions  and  con¬ 
stants  are  both  translated  into  Maude  operator  declarations.  In  Maude 
an  operator  is  defined  by  a  name,  a  list  of  argument  sorts  and  its  target 
sort.  Constants  are  operators  with  empty  argument  parameter.  For 
instance,  the  CAPSL  function  cat  (Field,  Field):  Tape,  ASSOC 
is  translated  into  op  cat  :  Field  Field  ->  Tape  [assoc].  We 
introduced  two  additional  boolean  operators  to  deal  with  invertibil- 
ity  statements:  op  INVERT_:_L  :  Field  Field  List  [Field]  -> 
Boolean  to  capture  invert ibility  axioms  that  have  a  list  of  fields  as 
third  parameter  and  op  INVERT_:„  :  Field  Field  ->  Boolean  to 
represent  invertibility  axioms  with  only  two  parameters. 

Variables  and  axioms.  Variable  declarations  such  as  VARIABLES  Al:Atom 
are  expressed  in  Maude  as  vax  A1  :  Atom.  CAPSL  axioms  are  rep¬ 
resented  by  Maude  (conditional)  equations.  For  instance,  the  axiom 
first(cat(Al,  XI))  =  A1  looks  like  this  eq  f irst (cat (A1,X1))  = 
A1  in  Maude.  IF-THEN-ELSE  axioms  such  as 

IF  keypair(PKl,PKIl)  THEN  ped(PKIl,  ped(PKl,  XI))  =  XI 
ENDIF 

can  be  represented  by  a  conditional  equation 

ceq  ped(PKIl,  ped(PKl,  XI))  -  XI 

if  (keypair(PKl,  PKIl)  ==  true). 

Properties.  As  for  properties,  associativity  (ASSOC)  and  commutativity 
(COMM)  are  supported  by  Maude.  The  privacy  property  PRIVATE  is 
treated  indirectly.  A  private  function  symbol  is  one  which  cannot  be 
accessed  by  the  attacker  (unless  the  symbol  is  private  to  the  attacker). 
We  provide  a  tailored  solution  to  assure  that  the  attacker  only  uses 
appropriate  functions  in  rewrite  rules.  CRYPTO  is  treated  similarly.  So 
far  we  only  handle  the  FRESH  property  of  Nonces  by  introducing  a 
counter  that  guarantees  freshness  of  nonce  values  (see  Section  5.3.4 
and  Section  5.3.5). 

Using  these  general  guidelines  we  translated  the  CAPSL  prelude  into  a 

Maude  module. 
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5.3*3  Definition  of  the  CIL  model 


The  flexibility  of  Maude  allows  us  to  simulate  CIL  rewrite  rules  using  a 
syntactical  representation  that  matches  a  mixfix^  version  of  the  CIL  notation 
of  Section  3.1.2.  In  order  to  achieve  this  goal,  we  provide  a  standard  Maude 
specification  that  defines  all  sorts,  operations  and  equations  necessary  to 
describe  the  specifics  of  a  CIL  model  such  as  state,  msg  and  intruder  facts. 
The  following  functional  theory  (i.e.,  a  functional  module  without  equations) 
defines  CIL  facts. 

fth  FACT  is 

protecting  FIELDS  . 
protecting  CAPSLPRELUDE  . 

sort  Fact  . 

op  Msg  :  Principal  Principal  Fields  “>  Fact  .  msg  fact 

op  State  :  Role  Machineint  Fields  ->  Fact  .  ***  state  fact 

op  Net  :  Fields  ~>  Fact  .  intruder  fact 

endfth 

The  imported  module  FIELDS  defines  an  operator  op  [_]  :  List  [Field] 
“>  Fields  .  to  represent  field  lists  enclosed  in  square  brackets  such  as 
[A,B,Na].  LIST  is  another  parameterized  module  that  defines  list  opera¬ 
tions.  The  CAPSL  prelude  is  also  imported  in  order  to  refer  to  the  sorts 
Principal  and  Role.  Multiset  of  facts  are  then  defined  by  the  following 
theory. 

fth  FACTS  is 

protecting  MSET[Fact]  . 
sort  Facts  . 

op  [_]  :  MSetEFact]  ->  Facts  . 

op  attack  :  ->  Facts  . 
endfth 

^We  prefer  to  use  the  mixfix  notation  over  prefix  notation  since  it  is  more  readable 
and  shortens  the  protocol  specifications.  Thus,  instead  of  using  the  prefix  operator  facts 
for  multisets  of  facts,  we  used  square  brackets  around  multisets  of  facts.  We  also  enclose 
term  lists  in  square  brackets. 
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The  imported  module  MSET[Fact]  defines  multisets  of  facts  using  for 
separating  facts.  The  term  [State(roleA,  1,  [A,B,Na]),  Msg(UNK,  A, 
[ped(pk(A),  cat (Na,Nb) )] )]  is  of  sort  Facts  due  to  the  above  theory 
(assuming  appropriate  variable  declarations).  This  representation  is  very 
close  to  the  OIL  notation  introduced  in  Section  3.1.2.  The  constant  attack 
of  sort  Facts  is  used  in  the  search.  For  a  given  protocol  specification,  we 
negate  the  goals  and  define  systems  states  as  patterns  that  invalidate  the 
goals.  We  then  define  equations  that  rewrite  a  system  state  that  invalidates 
a  goal  into  attack.  The  search  strategy  terminates  when  an  attack  state  is 
found.  Further  down  we  give  details  for  the  search  strategy. 

With  the  help  of  the  above  module  we  can  mirror  the  OIL  rules  in  Maude  in 
a  very  straightforward  way  with  only  few  alterations.  One  alteration  is  that 
Maude  rewrite  rules  need  a  label.  The  current  automated  CIL-to-Maude 
translator  numbers  the  rules  consecutively. 

5.3.4  Maude  Attacker  Model 

The  computational  capabilities  of  an  intruder  are  modelled  by  rewrite  rules. 
Information  that  can  be  extracted  from  messages  sent  to,  or  intercepted 
by,  the  attacker  are  stored  in  the  global  state  as  data  of  the  form  Net(l) 
where  1  is  a  variable  of  sort  Fields.  We  model  possible  attacker  actions 
using  additional  rules  that  intercept  messages  (and  place  them  on  the  net), 
fake  new  messages,  decompose  messages  on  the  net  and  place  their  parts 
on  the  net,  compose  messages  from  parts,  and  encrypt  messages.  We  give 
a  few  examples  here. 

crl  [intercept]  : 

CMsg(a,b,l),  fs]  =>  [Net(l),  fs] 

if  (not (Net (1)  in  fs)  and  not(spyOf (a)  ==  true))  . 
crl  [fake]  : 

[Net ([a]),  Net(l),  fs] 

=>  [Net ([a]),  Net(l),  Msg(Spy,a,l) ,  fs] 
if  (not(spyOf (a)  ==  true)  and  not (Msg(Spy,a,l)  in  fs))  . 
crl  [fake2]  : 

[Net  ([a]),  fs]  =>  [Net  ([a]),  Msg(Spy  ,a,  [a]  )  ,  fs] 
if  (not(spyOf (a)  ==  true)  and  not (Msg (Spy, a, [a] )  in  fs))  . 
crl  [decompose]  : 

[fs]  =>  [analyze (nets (partition(fs))) , 
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nonNe t  s (part ition(fs))] 
if  (card (analyze (nets (partition(f s) ) ) , 

nonNets(partition(f s)))  >  card(fs))  . 

The  intercept  rule  says  that  the  content  of  any  message  that  is  not  ad¬ 
dressed  to  a  spy  can  be  intercepted  by  it  (there  may  be  more  than  one  spy 
in  the  system)  if  the  spy  can  learn  some  new  data.  The  latter  condition, 
formalized  as  not  (Net  (1),  assures  that  the  intruder  only  intercepts  when 
she  gains  some  value  by  intercepting  the  message.  If  the  intruder  already 
knows  the  content  of  the  message,  that  is  Net(l)  in  fs  (fs  is  a  variable 
of  sort  fact  set),  than  intercepting  the  message  is  useless.  This  condition 
speeds  up  the  search  process  by  avoiding  exploring  unnecessary  states,  fake 
states  that  for  an  agent  a  on  the  network  and  for  a  message  1,  the  message 
Msg(Spy,a,l)  is  inserted  into  the  global  state.  The  condition  assures  that 
the  spy  does  not  send  a  faked  messages  to  himself  and  that  the  message 
is  new.  Note  that  we  have  adopted  the  convention  of  [Pau98]  where  the 
message  source  and  destination  arguments  are  the  true  source  and  intended 
destination  of  the  message,  and  they  are  not  accessible  to  the  receiver  of 
the  message.  Hence,  Spy  is  the  sender  here  (and  in  rcvMsgl  the  sender  is 
unknown).  The  rule  f  ake2  is  similar  but  allows  matching  with  only  one  state 
fact.  The  decompose  rule  is  implemented  in  such  a  way  that  in  one  step  the 
attacker  retrieves  the  maximum  amount  of  information  from  the  currently 
held  fields  by  applying  decomposition  and  decryption  functions  defined  in 
the  prelude.  The  decompose  rule  partitions  the  fact  set  into  attacker  facts 
and  non-attacker  facts.  The  function  analyzed  recursively  applies  decom¬ 
position  and  decryption  operators  on  the  attacker  facts  until  no  more  addi¬ 
tional  knowledge  is  extracted.  For  performance  reason^^,  this  rule  only  fires 
if  the  attacker  knowledge  can  be  increased.  In  order  to  achieve  determinism 
for  each  composing  step,  the  corresponding  rules  only  create  one  new  term 
using  one  of  the  composition  or  encryption  functions  defined  in  the  prelude. 
Thus,  for  each  of  the  constructional  operators  such  as  ped,  se,  con,  cat 
there  are  rules  in  the  Maude  attacker  module  that  describe  state  transitions 
that  create  new  attacker  facts.  The  attacker  might  need  to  apply  these  rules 
several  times  successively  in  order  to  build  a  composed  message  which  he 
wants  to  fake. 
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5.3.5  Translating  CIL  Protocols  and  Environments 


The  parts  of  a  CIL  specification  that  are  relevant  for  producing  the  corre¬ 
sponding  Maude  specification  are  Symbols,  Axioms,  Rules,  Environment, 
and  Goals. 


Symbols 

Symbol  declarations  are  translated  in  very  straightforward  manner  to  Maude. 
Depending  on  the  kind  of  symbol  declaration,  they  result  in  Maude  sort  and 
subsort  declarations  or  operator  declarations. 


Type  declarations.  A  type  declaration  symbol  (idenfi,type,ids  ()  ,irfen^>2, 
props  ())  turns  into  sort  declarations  with  associated  subsort  decla¬ 
rations:  sort  identl  and  subsort  identl  <  ident2. 

Constant  or  function  declarations.  The  declaration  symhol{ident^  op, 
args,  val,  props)  is  translated  into  op  ident  :  args  ->  val  [  props  ]  . 

Variable  declarations.  A  variable  declaration  symbol (iden^,  var/pvar, 
ids(),  val,  props)  corresponds  to  the  following  Maude  variable  decla¬ 
ration  vax  ident  :  val  . 

Properties  of  variables  cannot  be  expressed  directly  in  Maude.  So  far 
we  treat  FRESH,  CRYPTO,  and  EXPOSED  properties  in  the  connector  to 
Maude.  They  are  not  expressed  by  similar  Maude  concepts,  rather  we 
provide  tailor-made  solutions. 

For  the  sort  of  a  fresh  variable  we  define  constructors  that  fulfill  the 
freshness  requirement.  For  example  in  the  case  of  nonces,  our  cur¬ 
rent  implementation  uses  integers  to  enumerate  instances  of  a  sort, 
op  Nonce.  :  Machineint  ->  Nonce  defines  a  nonce  generator  that 
produces  Nonce  1,  Nonce  2,  ....  Machineint  is  a  Maude  specific 
data  type  for  integers.  There  are  several  ways  to  assure  freshness  of 
nonces.  We  chose  to  maintain  a  system  counter  as  part  of  the  protocol 
that  is  increased  each  time  a  fresh  variable  of  some  sort  is  generated. 

Analogous  to  the  PRIVATE  property  of  functions,  a  CRYPTO  property  of 
a  variable  is  expressed  implicitly.  That  means  that  no  attacker  rule  can 
make  use  of  a  crypto  variable,  unless  it  is  held  by  the  attacker  or  can 
be  generated  by  the  attacker  using  public  functions.  The  semantics  of 
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the  RANDOM  property  is  still  to  be  defined  in  CIL.  EXPOSED  terms  will 
be  handled  in  the  initial  state  of  an  attacker.  EXPOSED(sk(Alice)) 
is  translated  into  Net  (  [sk (Alice) ]  )  expressing  that  the  secret  key  of 
Alice  is  on  the  network  (and  thus,  known  to  the  attacker). 


Axioms 

It  is  relatively  easy  to  translate  CIL  Axioms  into  Maude.  CIL  only  uses 
equations,  boolean  predicates,  if-then-else  expressions  and  the  invertibility 
predicate.  Each  of  these  concepts  can  the  represented  via  conditional  equa¬ 
tions  in  Maude.  For  instance,  the  following  set  of  CIL  axioms 

axioms (if (keypair(Kl,K2) ,eqn(ped(Kl ,ped(K2 ,F)) ,F) ,true), 
keypair(sk(U) ,pk(U)), 

invert ible (ped (pk (U) ,F) ,  F,  terms(sk(U))) 

translates  into  the  Maude  (conditional)  equations 

ceq  ped(Kl,ped(K2,F))  -  F  if  keypair (K1 ,K2)  . 

eq  keypair  ( sk  (U)  ,pk(U))  =  true  . 

eq  INVERT  ped(pk(U),F)  :  F  I  sk(U)  =  true  . 


Rules 

Using  the  Maude  module  for  the  CIL  model,  we  can  mirror  CIL  rewrite 
rules  almost  identically  in  Maude.  There  are  two  main  differences.  For 
one,  rules  in  Maude  have  to  be  labelled.  We  currently  number  rules  rules 
consecutively.  The  second  difference  is  that,  depending  on  the  solution  we 
chose  for  generating  fresh  values,  additional  predicates  might  show  up  in  the 
rules.  This  cannot  be  avoided,  since  the  abstract  concept  of  fresh  values  has 
to  be  implemented  in  an  executable  formalism  like  Maude.  In  the  following 
we  chose  to  use  a  counter  fact  Cnt  (n) ,  which  determines  the  next  available, 
fresh  integer  in  order  to  create  nonces.  The  counter  is  updated  any  time  a 
nonce  is  created.  Though  the  counter  is  not  by  itself  secret,  and  thus,  it 
looks  as  if  the  attacker  can  generate  any  nonce  (including  those  generated 
by  honest  agents),  we  assure  in  the  attacker  model,  that  the  attacker  does 
not  access  the  counter,  unless  to  create  its  own  nonces. 
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The  following  rules  correspond  to  the  CIL  rules  for  NSPK  for  sending  and 
receiving  the  first  message. 

rl  [1]  : 

[State(roleA,0, [A,B] ) ,Cnt (n) ,fs] 

=>  [State(roleA,l, [A,B,Nonce  (n+1)]), 

Msg(A,B, [ped(pk(B) , cat (Nonce  (n+1) ,A))] ) ,Cnt (n+1) ,f s]  . 

rl  [2]  : 

[State(roleB,0, [B] ) ,Msg(UNK,B, [ped(pk(B) ,cat(Na,A) )] ) , 

Cnt (n) ,fs] 

=>  [State(roleB,l, [B,Na,A]) ,Cnt(n) ,fs]  . 

f  s  is  a  free  variable  that  matches  the  remaining  facts  in  the  multiset. 

Conceptually,  initialization  rules  could  be  translated  one-to-one  into  Maude 
rules: 

rl  [initA]  : 

[mt]  =>  [State(roleA,0, [A,B] )]  . 

The  problem  with  such  an  initialization  rule  is  that  it  is  always  enabled  since 
mt  is  the  identity  element  of  the  multiset  operator  [J  for  facts,  and  thus, 
any  system  configuration  has  mt  as  a  sub-configuration.  This  would  unnec¬ 
essarily  cause  the  Maude  model  checker  to  loop  infinitely.  Moreover,  the 
variables  on  the  righthand  side  are  free.  The  Maude  model  checker  needs  to 
bind  variables  to  values  in  order  to  execute  the  protocol  for  specific  agent  in¬ 
stantiations.  To  resolve  both  problems,  we  decided  to  skip  the  initialization 
rules  and  instead  provide  a  means  of  setting  up  agents  for  model  checking 
sessions  by  using  the  environment  information. 


Environment 

Each  test  environment  results  in  an  initial  configuration  that  is  modelled 
as  a  fact  set.  Currently,  we  only  handle  environment  in  which  all  agents 
exists  concurrently.  Here  is  the  initial  state  for  the  test  environment  Testl 
of  NSPK  given  in  Section  2.5. 

op  Testl  :  ->  Facts  . 
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eq  Testl  =  [St ate (role A, 0,  [Alice , Bob] ) , 

State(roleB,0, [Bob] ) , 

Net ( [Mallory] ) ,Net ( [Alice] ) ,  Net (  [Bob] )  , 
Net([ped(sk(Alice) ,Bob)])  ]  . 

The  attacker  knows  the  names  of  all  principals  that  are  part  of  the  session 
and  the  exposed  term. 


Goals 

The  secrecy  goal  for  Na  in  NSPK  is  localized  into  the  CIL  goal  loc(  nodes  ( 
node(roleA,3) ,  node(roleB,3)) ,  secret  (Na,ids(A,B))).  This  goal  is 
violated  for  an  agent  A,  if  the  A-agent  is  in  a  session  with  another  honest 
agent,  has  the  nonce  Na  in  its  memory,  and  the  spy  also  knows  this  nonce 
(i.e.,  Net([Na])  is  in  the  multiset  of  facts).  Therefore,  we  can  characterize 
what  states  represent  attacks.  For  the  given  NSPK  secrecy  goal,  a  state  rep¬ 
resents  an  attack  when  an  agent  has  sent  his  nonce,  encrypted,  to  another 
agent  (different  from  the  spy)  but  the  nonce  has  been  compromised  by  the 
spy,  i.e.,  is  on  the  net.  For  efficiency  reasons,  we  implement  this  characteriza¬ 
tion  in  the  following  way.  We  search  for  the  smallest  A-state  that  contains  the 
secret  Na.  For  NSPK  this  is  State (roleA,l,  [A,B,Na]).  Since  the  A-agent 
can  grow  over  time,  the  state  number  can  change  and  there  might  be  addi¬ 
tional  slots  after  Na.  Thus,  we  use  the  pattern  St  ate  (role  A,  n,  [A,B,Na,fl] ) 
where  the  free  variable  f  1  matches  the  rest  of  the  fields. 

A  violation  of  the  secrecy  goal  for  Na  is  defined  by  the  following  axiom, 
ceq  [Net  ( [Na] ) , 

State(roleA,n, [A,B,Na,fl]) ,  fs]  =  attack 
if  not(spy0f(A)  ==  true)  and  not(spy0f (B)  ==  true)  . 

The  predicate  spyOf  determines  that  the  nonce  was  not  deliberately  sent  by 
an  agent  to  an  intruder. 

PRECEDES  goals  can  also  be  interpreted  in  Maude  with  the  help  of  additional 
equations.  The  PRECEDES  goal  loc (nodes (node (roleA, 3)  ,node(roleB,3)) , 
precedes  (B,  A,  ids  (Na)))  is  fulfilled  whenever  B  is  in  its  final  (third)  state 
in  which  it  holds  a  value  for  A,  B,  and  Na,  then  there  exists  an  agent  in 
role  A  that  agrees  with  B  on  these  values.  Here  is  the  appropriate  Maude 
formalization 
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ceq  [State(roleB,3, [B,Na,A,Nb] ) ,fs)  =  attack 
if  not (State(roleA,n, [A,B>Na,fl] )  in  fs) 

and  not(spyOf(A)  ==  true)  and  not(spyOf(B)  ==  true)  . 


5.3.6  Search  Strategy  and  Optimization 

The  aim  of  model  checking  is  to  explore  the  state  space  for  possible  attacks. 
In  problems  like  ours  where  the  state  space  is  infinite,  model  checking  based 
on  enumerative  search  constitutes  a  semi-decision  procedure. 

By  applying  rewrite  rules,  Maude  can  be  used  to  build  parts  of  the  compu¬ 
tation  tree  rooted  at  the  initial  state.  In  particular,  the  Maude  interpreter 
delivers  one  particular  branch  of  the  computation  tree  determined  by  in¬ 
terpreter’s  default  evaluation  strategy  for  applying  rules.  However,  to  find 
possible  attacks  we  need  to  explore  all  possible  branches. 

We  proceed  by  employing  Maude’s  metalevel  reasoning  capabilities  and  de¬ 
fine,  at  the  metalevel  (in  Maude),  a  strategy  that  specifies  how  the  rules 
should  be  applied.  To  do  this  we  define,  within  a  Maude  module,  a  function 
that  implements  an  iterative  deepening  search  on  a  tree  specified,  implicitly, 
by  an  initial  state  and  rewrite  rules  of  another  module.  Writing  the  search 
strategy  for  model-checking  on  the  meta-level  allows  to  import  any  protocol 
description  and  run  the  search  strategy  with  that  protocol.  Thus,  we  spe¬ 
cialize  the  search  strategy  to  the  given  initial  protocol  state  and  the  module 
defining  the  protocol  rules.  In  doing  so,  the  protocol  specification  becomes 
a  term  on  the  metalevel  that  is  passed  to,  and  manipulated  by,  the  search 
strategy. 

(fmod  SEARCH  is 
protecting  META-LEVEL [NSPK]  . 

endfm) 

For  practicality  reasons  we  defined  a  bounded  depth-first  search  strategy 
instead  of  a  breadth-first  search  strategy.  A  breadth-first  search  strategy 
can  be  obtained  by  iteratively  calling  the  depth-first  strategy  with  increas¬ 
ing  depths.  To  specify  a  depth-first  search  strategy,  we  formalize  a  func¬ 
tion  whose  arguments  are  the  protocol  module  in  which  the  reduction  takes 
place,  the  current  search  path  (i.e.,  a  sequence  of  steps,  where  each  step  is  a 
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triple  consisting  of  a  rule  label,  a  Maude-internal  substitution  number,  and 
the  new  term),  the  current  depth  of  the  search  tree,  the  maximum  depths, 
and  a  list  of  protocol  rule  names  (quoted  identifier  list  QIDL).  Initially,  the 
path  is  the  initial  test  term  as  defined  by  the  environment  specification 
op  bdfs  :  Module  Path  Machineint  QidList  ->  Strategy  .  Qid  is  a 
Maude  specific  data  type  for  strings. 

Below  we  show  part  of  our  bounded  depth  first  seach  strategy. 

ceq  bdfs(M,path(APATH,step(L,N,T)) , DEPTH, MAX, QIDL) 

=  if  DEPTH  <  MAX 

then  (if  nextRewrite(M,  T,  L,  QIDL)  =  none 

then  backtrack(M,path(APATH,step(L,N,T)) , 

DEPTH, MAX, QIDL) 

else  ids (M, path (path (APATH, St ep(L,N,T)) , 
nextRewrite (M , T , L , QIDL) ) , 

DEPTH  +  1, MAX, QIDL) 
fi) 

else  backtrack(M,path(APATH,step(L,N,T)) , DEPTH, MAX, QIDL) 
fi 

if  T  =/=  attack}^ Facts  . 

ceq  bdfs (M,  path(APATH,  step(L,  N,  T)),  DEPTH,  MAX,  QIDL) 

=  stop (DEPTH,  path (APATH,  step(L,  N,  T))) 
if  T  ==  {’attack} ’Facts  . 

The  strategy  conceptually  builds  a  search  tree,  where  each  node  corre¬ 
sponds  to  a  state  of  the  protocol,  and  each  successor  node  is  reached  by 
applying  a  rewrite  rule,  matching  the  variables  of  the  rule  with  values 
from  the  current  multiset  of  facts.  The  search  strategy  remembers  the 
current  path  of  the  search  tree  as  a  sequence  of  steps.  A  step  records 
the  latest  rule  that  has  been  applied,  the  substitution  number  (that  is 
a  Maude  specific  number  from  which  one  can  derive  the  substitution  be¬ 
tween  the  protocol  state  and  the  rule  variables)  and  the  new  protocol  state 
(op  step  :  Qid  Machineint  Term  ->  Step). 

For  a  given  state,  this  strategy  performs  a  rewrite  step  that  generates  a 
successor  state.  At  each  step,  we  test  for  an  attack  or  backtrack  in  case  the 
branch  terminates  or  the  maximum  depth  is  reached. 

{’attack} ’Facts  is  the  representation  of  the  NSPK  term  attack  at  the 
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search  met  a- level. 


In  theory,  iterative  deepening  can  find  any  attack,  but  in  practice  heuristics 
are  needed  to  do  so  using  manageable  resources.  The  performance  of  a 
search  strategy  like  the  one  above  can  be  enhanced  significantly  if  one  adds 
heuristics  that  tune  the  model  checking  process  to  the  application  at  hand. 
In  the  case  of  security  protocols  analysis  we  have  gained  lots  of  experience 
by  model  checking  several  protocols.  In  the  following  we  summarize  our 
main  ideas  to  speed  up  the  model  checking  process. 


Protocol-independent  Optimization 

Which  rules  and  in  what  order  those  rules  are  applied  has  an  impact  on 
the  performance  of  the  model  checker.  Our  optimization  techniques  and 
heuristics  for  the  Maude  model  checker  either  eflFectively  prune  the  search 
tree  or  reorder  it. 


Discarding  rules.  Some  rules  might  be  redundant  in  the  sense  that  they 
are  not  necessary  to  find  attacks.  For  instance,  the  overhear  rule  of  an 
the  attacker  is  an  example  of  such  a  rule.  As  long  as  there  are  rules 
for  intercepting  and  faking  a  message,  the  effect  of  overhearing  a  rule 
can  always  be  simulated  by  replaying  it.  Therefore,  we  chose  not  to 
implement  such  a  rule  in  our  attacker  model. 

Prioritizing  rules.  During  the  process  of  building  the  search  tree  one  can 
apply  re-ordering  functions  that  give  priorities  to  rules  which  are  ex¬ 
pected  to  lead  faster  to  attacks.  This  is  a  heuristic  in  the  sense  that  for 
different  protocols  and  attacks  different  heuristics  might  turn  out  to  be 
better.  In  the  protocols  we  investigated  we  were  successful  with  order¬ 
ing  the  Maude  rewrite  rules,  such  that  the  attacker  intercept  rule  gets 
high  priority,  next  followed  by  the  rules  which  describe  the  protocol, 
and  lower  priorities  for  the  other  attacker  rules,  with  the  composition 
rules  having  the  lowest  priority.  Essentially  we  followed  the  intuition 
that,  the  more  restricted  the  enabling  condition  for  a  rule  is,  the  less 
likely  it  is  that  it  will  occur.  Thus,  giving  it  a  high  priority  does  not 
result  in  search  trees,  in  which  those  rules  are  always  applied  first. 
This  is  similar  to  optimization  techniques  suggested  by  Shmatikov  et 
al  [SS98].  In  their  approach  an  intruder  always  intercepts  (our  weaker 
version:  intercept  has  high  priority),  and  an  intruder  does  not  send 
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if  an  honest  agent  can  send  (our  version:  protocol  rules  have  higher 
priority  then  fake  rules). 

Restricting  rules  sequences.  Another  optimization  technique  we  used 
was  to  prune  the  search  tree  such  that  each  sequence  of  applied  rules 
satisfies  special  successor-rule  conditions.  For  example,  once  an  at¬ 
tacker  fakes  a  message,  he  does  that  with  the  intent  of  some  agent 
receiving  that  message.  Thus,  during  the  search  we  assure  that  a  fake 
rule  is  always  followed  by  a  rule  which  denotes  the  receipt  of  the  mes¬ 
sage.  Moreover,  optimization  steps  as  discussed  in  Chapter  4  can  also 
be  implemented  on  the  meta-level  of  search.  In  [BDOO]  we  formalize 
that  certain  action  sequences  must  occur  as  a  block  (without  other 
interleaved  actions).  For  example,  local  computations  of  agents,  such 
as  receiving  a  message,  followed  by  internal  computations,  followed  by 
sending  a  new  message,  can  be  summarized  to  one  step.  Similarly,  a 
message  which  was  intercepted  by  an  attacker  should  be  decomposed 
in  the  subsequent  step.  One  can  define  arbitrary  dependencies  between 
rules  and  enforce  their  order  in  the  search  strategy. 

As  long  as  those  dependencies  are  only  used  to  reorder  the  search  tree, 
there  is  no  danger  of  missing  out  on  an  attack.  In  those  cases  where 
one  can  show  that  the  optimization  preserves  all  attacks,  one  can  even 
prune  the  search  tree. 

The  above  listed  optimization  ideas  have  been  implemented  in  Maude  on 
the  meta-level, and,thus,  they  are  independent  of  the  protocol  to  which  the 
search  is  applied.  Further  details  can  be  found  in  [BDOO]. 


Protocol-dependent  Optimization 

Other  optimization  techniques  depend  heavily  on  the  protocol  which  is  to 
be  analyzed.  We  made  use  of  two  techniques. 

Message  format  This  technique  tests  the  message  format  of  composed 
and  faked  messages.  For  this  purpose  we  added  conditions  to  the  fake- 
rule  and  the  rules  for  composing  (i.e.,  concatenation  or  encryption) 
such  that  they  are  only  enabled  if  the  resulting  field  fulfills  the  for¬ 
mat  of  the  message  contents  of  the  protocol.  We  defined  a  predicate 
isInMsgContent Format  that  is  defined  to  be  true  for  any  field  that 


85 


has  (partially)  the  format  of  a  valid  protocol  message.  The  following 
describes  part  of  the  definition  for  NSPK. 

eq  Net([A,Na])  isInMsgContent Format  =  true  . 

eq  Net ( [ped(K,cat (Na,A))] )  isInMsgContentFormat  =  true  . 

Receivability  of  faked  messages.  Moreover,  we  test  whether  a  faked  mes¬ 
sage  is  receivable  in  a  given  state  of  the  protocol.  For  instance,  the 
first  message  of  NSPK  is  receivable  whenever  an  agent  in  role  B  in 
state  zero  exists  in  the  multiset  of  facts. 

eq  Msg(UNK,b, [ped(pk(B) ,cat (Na,A))] )  isReceivableIn 
[State(roleB,0,  [B] ) ,  fs]  =  true  . 


5.3.7  Conclusion 

In  the  process  of  designing  a  CIL  connector  to  Maude,  we  tackled  some 
essential  issues  about  the  practicability  of  a  connector.  Our  aim  is  not  just 
to  translate  the  CIL  specification  into  an  executable  Maude  specification, 
but  to  yield  an  efficiently  executable  and  practically  analyzable  protocol 
specification.  In  order  to  meet  this  goal,  we  solved  the  issues  involved  in 
translating  CIL  into  an  equivalent  Maude  specification  and  we  proposed  and 
fine-tuned  several  optimization  techniques  that  will  improve  the  performance 
of  the  Maude  model  checking  tool. 

A  prototype  of  the  CIL-to-Maude  connector  has  been  implemented  in  Java 
using  the  existing  support  classes.  The  implementation  of  the  CIL-to-Maude 
connector  took  one-person  week. 

As  mentioned  before  the  current  connector  is  restricted  on  the  predefined 
data  types  of  the  CAPSL  prelude  and  supports  the  optimization  strategies 
discussed  in  the  previous  session.  Order  specification  in  environment  decla¬ 
rations  are  not  yet  handled.  In  environment  specifications  one  can  define  a 
principal  as  exposed,  meaning  that  all  the  secrets  of  that  principal  are  known 
to  the  attacker.  This  issues  needs  to  be  addressed  in  future  extensions  of 
the  connector.  Further  investigation  is  also  necessary  in  order  to  define  the 
semantics  of  protocol  goals  other  than  secrecy  or  agreement  goals. 
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5.4  Athena 


Athena  is  a  model  checker  for  security  protocols  [Son99],  based  on  the  strand 
space  representation  [THG98].  The  required  input  format  for  Athena  was 
obtained  from  draft  material  supplied  by  its  author,  Song. 

An  Athena  specification  has  two  parts:  a  sequence  of  strands  and  a  sequence 
of  verification  conditions.  A  strand  is  a  sequence  of  nodes.  A  node  consists 
of  a  “sign”  or  direction  (send  or  receive,  represented  by  and  and 
a  term  representing  the  content  of  a  message.  Nonces  introduced  or  “origi¬ 
nated”  in  a  sent  message  are  also  listed.  A  strand  specification  of  a  protocol 
is  a  parametric  strand  in  the  sense  of  [CDL‘^00],  which  addresses  transla¬ 
tions  between  MSR  and  strand  space  protocol  models  in  a  general  setting. 
A  strand  specification  is  parameterized  by  the  list  of  protocol  variables  that 
must  be  instantiated  to  create  a  particular  strand. 

Here  is  the  “A”  strand  from  the  NSPK  example  in  Athena: 

P.A(0,3)  { 

VAR:  P^A,  P^B,  NONCE.Na,  NONCE^Nb; 

->  :  E{C[N0NCE3a,P„A]  ,PUBKEY^P_B} 

I  New(NONCE_Na) ; 

<-  :  E{C[N0NCE3a,N0NCE.Nb]  ,PUBKEY_P_A}; 

:  E{NONCE^Nb,PUBKEY^P^B}; 

} 

Issues  in  writing  a  connector  to  Athena  come  up  in  five  areas: 

1.  The  basic  translation  strategy  to  produce  strands 

2.  Normalization:  non-message  rules 

3.  Type  and  function  limitations 

4.  Goal  generation 

5.4.1  The  Translation  Strategy 

OIL  rewrite  rules  update  the  state  of  exactly  one  role  at  a  time.  A  rule  may 
have  a  received  message  on  the  left  or  a  sent  message  on  the  right,  or  both. 
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A  message  on  the  left  generates  a  “receive”  node  in  the  strand  associated 
with  the  rule’s  role,  and  a  message  on  the  right  generates  a  “send”  node 
for  the  same  role.  Any  variables  listed  as  nonces  of  the  rule  become  nonces 
of  the  send  node.  In  [CDL'^00],  MSR  specifications  were  “normalized”  to 
generate  all  nonces  in  the  initialization  rule  of  each  role,  but  we  do  not  do 
that,  because  we  would  lose  the  information  as  to  which  node  originated  the 
nonce,  which  is  required  for  Athena. 

Rewrite  rules  are  not  required  to  be  in  the  expected  order  associated  with 
message  events  or  state  changes,  and  the  connector  was  written  so  that  nodes 
will  be  added  in  the  correct  sequence  regardless  of  the  rule  order.  However, 
the  CAPSL  translator  now  generates  rules  in  the  expected  order,  primarily 
to  make  the  rule  output  as  readable  as  possible,  and  future  connectors  should 
be  able  to  take  advantage  of  that. 

There  must  be  a  strand  for  each  role  in  the  protocol.  To  find  the  roles,  we 
can  get  a  list  of  symbols  of  type  Role  from  the  CIL  symbol  table;  but  this 
not  quite  right  because  the  translator  generates  a  role  constant  for  every 
variable  of  type  Principal.  Such  a  variable  is  usually  a  role,  but  it  could  be 
just  a  message  field,  and  the  translator  does  not  check  whether  a  message  is 
actually  sent  to  or  from  that  principal.  The  connector  generates  an  empty 
strand  for  a  non-role  principal,  which  is  a  nuisance  but  not  a  serious  problem. 
The  CAPSL  translator  should  probably  refrain  from  generating  roles  for  such 
variables. 

The  strand  parameters  are  the  protocol  variables  that  must  be  instantiated 
to  produce  a  particular  strand.  These  variables  occur  as  slots  in  states  of 
the  strand’s  role,  and  they  are  found  in  the  slot  table. 

Once  the  protocol  variable  parameters  used  by  the  strand  are  found,  we 
have  to  ensure  that  these  same  variables  are  used  in  the  strand  node  specifi¬ 
cations.  Strands  are  generated  from  rewrite  rules,  but,  as  remarked  earlier, 
the  variables  in  rewrite  rules  are,  in  principle,  dummy  variables  that  are 
subject  to  renaming,  and  the  renaming  can  be  different  in  each  rule.  The 
CAPSL  translator  ordinarily  uses  the  original  protocol  variables  in  the  rules, 
for  the  sake  of  rule  readability,  but  there  is  presently  no  guarantee  of  that. 
Hence  the  connector  replaces  the  rule  variables  with  protocol  variables.  This 
is  done  using  the  slot  table.  The  protocol  variable  corresponding  to  a  rule 
variable  is  found  by  observing  which  slot  it  occupies  in  the  rule’s  right-hand 
state  fact,  which  should  have  them  all. 

In  an  Athena  specification,  variable  names  are  prefixed  by  the  variable  type 
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name.  The  mapping  of  CAPSL  type  names  to  corresponding  Athena  type 
names  is  built  into  the  present  connector.  This  topic  is  discussed  further 
below  under  the  limitations  issue. 


5.4*2  Normalization:  Non-Message  Rules 

A  normalized  MSR  rule  in  [CDL'‘‘00]  either  sends  or  receives  one  message. 
CIL  rules  may  have  a  message  on  both  the  receive  and  the  send  side,  and  they 
could  also  have  no  messages,  as  in  the  case  of  state  initialization  rules,  actions 
that  assign  a  value  to  a  new  variable,  and  actions  that  test  an  equation  or 
other  boolean  condition. 

Initialization  rules  are  not  a  problem;  they  just  create  a  strand  to  which 
nodes  will  be  added.  Rules  that  both  send  and  receive  messages  are  also 
no  problem,  they  just  create  two  nodes.  Non-initialization  rules  with  no 
messages  are  a  problem  because  no  node  is  created  for  them;  the  information 
they  carry  is  lost. 

An  assignment  action  in  CAPSL,  such  as  C  =  A,  generates  a  rule  like 
Bi(J5,A)  B2{B^A^A)  and  creates  a  slot  table  entry  for  C  as  slot  3  of 
B,  Later  rules  will  refer  to  slot  3  of  5  by  the  variable  C  without  regard  for 
its  value.  For  example,  the  message  B  ^  A  :  C  becomes  J52(-B,A,  (7) 
Bs{B^  A,  C),  M (j5,  A,  C),  The  B  strand  will  have  A,  B  and  C  as  parameters, 
and  the  connector  will  give  it  a  node  to  send  C,  The  correct  strand  should 
send  A  instead. 

Fortunately,  the  assignment  action  problem  goes  away  because  the  CAPSL 
optimizer  combines  assignment  rules  with  other  rules,  so  that  the  CIL  out¬ 
put  only  has  the  single  rule  Bi(R,A)  £3(5,  A,  A),M(j5,  A,  A),  which 
generates  the  correct  node.  This  may  be  viewed  as  a  kind  of  normalization 
step. 

We  are  less  fortunate  with  test  actions.  A  test  (7  =  A  (in  a  state  where 
C  and  A  are  held)  generates  two  rules,  one  to  evaluate  the  equation  and 
one  to  continue  if  it  is  true:  R2(-B,A,  C)  jB3(S,A,  C,  C  =  A)  and 
53(5,  A,  (7,  true)  £3(5,  A,  C).  Neither  of  these  generates  a  node,  and 
the  information  that  (7  =  A  is  lost.  Both  C  and  A  are  strand  parameters, 
and  they  could  be  instantiated  to  be  unequal  to  produce  a  strand  that  is 
inconsistent  with  the  protocol.  Furthermore,  the  optimizer  does  not  help 
here;  it  can  only  combine  the  second  rule  with  a  later  one. 
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The  way  to  handle  this,  at  the  moment,  is  just  to  write  the  protocol  without 
putting  in  test  actions.  Most  protocols  don’t  need  them;  their  main  purpose 
in  CAPSL  is  to  control  conditional  branching,  an  advanced  feature. 


5.4.3  Type  and  Function  Limitations 

CAPSL  permits  new  field  types,  as  well  as  new  encryption  and  other  compu¬ 
tational  functions,  to  be  introduced  using  abstract  datatype  specifications 
(called  typespecs  in  CAPSL).  Analysis  tools  are  often  limited  in  their  adapt¬ 
ability  to  extensions.  Like  the  PVS  tools  we  are  developing,  Athena  can 
presently  deal  only  with  simple  abstract  operators.  The  ones  currently  sup¬ 
ported  are  public-key  and  symmetric-key  encryption,  concatenation,  hash¬ 
ing,  MAC  (keyed  hash)  and  a  few  standard  data  types  like  P  for  principals 
and  NONCE  for  nonces.  The  connector  translates  the  equivalent  CAPSL  stan¬ 
dard  types  and  functions  (in  the  prelude)  into  them  -  for  example,  Principal 
to  P,  ped(,,.)  to  etc. 

For  types  and  functions  without  equivalents  in  Athena,  the  connector  pre¬ 
serves  their  names,  and  they  appear  in  the  connector  output.  The  Athena 
user  can  then  see  the  unrecognized  symbols  and  attempt  to  rewrite  the  pro¬ 
tocol  specification  without  them.  The  connector  can  be  modified  easily  to 
add  more  types  and  functions.  When  future  versions  of  Athena  permit  user- 
defined  new  field  types  and  functions,  the  connector  will  have  to  be  extended 
to  make  use  of  the  symbol  table  and  axiom  entries  in  the  CIL. 

5.4.4  Goal  Generation 

Goals  in  Athena  are  specified  with  a  list  of  partially  instantiated  strands, 
with  conditions  as  to  which  combinations  of  these  strands  are  permitted 
to  appear  in  a  bundle.  A  secrecy  goal  says  that  a  strand  with  a  given 
value  for  a  secret  variable  is  not  compatible  with  a  standard  intruder  (or 
“penetrator” )  “flush”  strand  with  the  same  value.  An  agreement  goal  says 
that  the  existence  of  a  strand  with  values  for  certain  variables  implies  the 
existence  (in  the  same  bundle)  of  another  strand  with  the  same  values  for 
the  same  variables.  These  goals  can  be  generated  in  a  straightforward  way 
from  the  SECRET  and  PRECEDES  goals  in  CAPSL. 

In  the  current  version  of  Athena,  symbolic  constants  used  to  indicate  values 
of  variables  are  always  formed  simply  by  appending  “0”  to  the  name  of  the 
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variable,  and  the  connector  does  that.  More  general  value  assignments  are 
possible  in  CAPSL  through  the  use  of  environment  modules. 

As  an  example,  the  CAPSL  goal  appearing  in  CIL  as  precedes  (B ,  A ,  ids  (Na) ) 
says  that  if  A  reaches  its  final  state,  there  is  or  was  a  state  of  B  agreeing 
with  A  on  A,  and  Na.  This  goal  is  stated  in  Athena  as: 

VC.  {Strand(0,3) [(P^B,B0) , (P_A,A0) , 

(NONCE^Na,NaO)]}  => 

{Strand(l,3) [(P.B,BO) , (P_A,A0) , 

(NONCE.Na,NaO)]} 


where  strand  0  is  the  A  strand  and  strand  1  is  the  B  strand. 
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Chapter  6 

Concluding  Remarks 


CAPSL,  CIL  and  the  translation  between  them  are  designed  to  address 
important  goals  in  cryptographic  protocol  specification  for  analysis  pur¬ 
poses.  With  a  common  specification  language,  it  becomes  possible  to  har¬ 
ness  the  combined  power  of  many  tools  for  protocol  analysis  in  a  practical 
way.  The  components  of  the  CAPSL  environment  include  transportable 
software  for  translation  of  CAPSL  to  CIL,  and  connectors  to  adapt  CIL  to 
the  input  languages  of  various  analysis  tools.  This  software  is  still  under 
development,  but  a  CAPSL-to-CIL  translator  is  available  on  the  Web  site 
http ;  //www .  csl .  sri .  com/^'millen/capsl.  The  site  also  contains  more  ex¬ 
amples  of  CAPSL  specifications  and  other  documentation. 

With  CAPSL,  one  can  express  protocols  in  the  simplest  accepted  message- 
list  form.  Type  specifications  in  CAPSL  and  their  use  for  introducing  new 
operators  and  subtypes  bring  an  expanding  class  of  protocols  within  reach. 
There  are  plans  to  broaden  the  applicability  of  CAPSL  further  with  exten¬ 
sions  for  multicast  protocols. 

CAPSL  simplifies  what  used  to  be  the  most  awkward  aspect  of  abstract 
protocol  specification,  the  distinction  between  short-term  session  data  and 
the  long-term  data  associated  with  persistent  entities.  This  was  done  by 
applying  the  general  type  specification  mechanism,  together  with  the  novel 
concepts  of  private  functions  and  invertibility  axioms. 

The  intermediate  language  CIL  was  chosen  with  an  eye  toward  a  clear 
analysis-level  modeling  semantics  and  a  universal  pattern-matching  tran¬ 
sition  rule  style  that  lends  itself  both  to  model  checking  and  inductive  proof 
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techniques. 

We  have  techniques  for  inductive  protocol  proof  using  PVS  and  model  check¬ 
ing  using  Maude.  In  the  process,  we  have  confirmed  that  CIL  output  is  a 
good  match  for  the  specification  needs  of  these  tools.  With  the  Athena  con¬ 
nector,  we  have  made  a  start  on  linking  CAPSL  to  independently  developed 
analysis  tools  as  well. 
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Appendix  A 

CAPSL  and  CIL  Syntax 

A.l  CAPSL  Syntax 


Here  is  an  informal  presentation  of  the  CAPSL  concrete  syntax.  In  this 
grammar,  curly  brackets  {  }  indicate  a  sequence  of  one  or  more  of  the 
enclosed  item.  A  vertical  bar  —  separates  choices.  Optional  items  are 
enclosed  in  square  brackets  [  ].  Literal  tokens  appear  enclosed  in  single 
quotes  except  for  keywords,  which  are  all  caps. 

There  is  a  general  meta-rule  for  forming  nonterminals  representing  lists.  If 
X  is  a  nonterminal  symbol,  then  x_list  represents  zero  or  more  occurrences 
of  X  separated  by  commas. 

Comments  in  CAPSL  are  surrounded  by /*  */,e.g.,/*  this  is  a  comment 
*/. 

The  grammar  permits  constructs  that  are  illegal  for  semantic  reasons,  such 
as  improper  ordering  or  type  inconsistency.  The  grammar  also  permits  some 
illegal  constructs  that  could  have  been  eliminated  with  a  more  elaborate 
grammar,  but  can  also  be  handled  by  later  checks.  An  example  is  that  the 
%  operator  should  be  used  only  in  message  fields. 

Identifiers  are  sequences  of  alphabetic  characters  and  digits,  and  may  also 
contain  the  underline  _  character.  An  identifier  that  consists  solely  of  digits 
is  a  number. 

specification: 


99 


{protocol  1  typespec  I  environment} 
protocol: 

PROTOCOL  ident  ' ; ’ 

{declaration} 

[ASSUMPTIONS 

{assertion  ‘;^}] 

MESSAGES 

phrase^seq 

[GOALS 

{assertion  ^;^}] 

END; 

typespec: 

TYPESPEC  ident 
{declaration} 

AXIOMS  {statement  ^;’} 

END; 

environment : 

ENVIRONMENT  ident  ' ; ^ 

{declaration} 

[AXIOMS 

{statement  ^;^}] 

{agent} 

[EXPOSED  term^list 
[ORDER  order 
END; 

agent : 

AGENT  ident  HOLDS 
{equation  ^;^} 

order : 

ident  /*  of  agent  */ 

I 

‘ ^  order  ' ; ^  order  ‘ ’ 

I 

‘  '  order  Ml’  order  ‘ ^ 
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declaration; 

IMPORTS  ident.list 

I 

FUNCTIONS  -Cfunc.dec} 

I 

VARIABLES  {variable.dec} 

I 

CONSTANTS  {variable.dec} 

I 

DENOTES  {equation  ’  ident_list] 

1 

TYPES  {type.dec} 
assertion: 

HOLDS  ident  ‘ : ’  ident_list 

I 

BELIEVES  ident  ‘ : ’  assertion 

I 

KNOWS  ident  ‘ : ’  assertion 

I 

ASSUME  assertion  /*  as  an  action  */ 

I 

PROVE  assertion  /*  as  an  action  ♦/ 

I 

SECRET  ident  ident_list] 

I 

AGREE  ident_list  ' : ’  ident_list  ‘ | ’  ident_list 

I 

PRECEDES  ident  ‘ : ’  ident  ‘ I ’  ident_list 

I 

statement 

statement : 
logic stmt 

I 

IF  logicstmt  THEN  simplestmt  [ELSE  simplestmt]  ENDIF 

I 

INVERT  term  ‘ : ’  ident  I  term_list 
logicstmt : 
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simple  stmt 


NOT  simplestmt 

simplestmt : 
equation 

I 

term 

equation: 

term  term 

variable_dec: 

ident_list  ident  ’  property.list] 
type.dec : 

ident^list  ^  ident] 
f unc_dec : 

ident  ident^list  ident  property^list] 

phrase.seq: 

phrase 

I 

phrase  [V']  phrase_seq 

phrase : 

[{action 

message 

[{action 

I 

invocation 

I 

selection 

action: 

equation  I  ASSUME  assertion  |  PROVE  assertion 
invocation: 

INCLUDE  ident  ^ ’  /♦  naming  a  protocol  ♦/ 
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selection: 

IF  statement  THEN  phrase  ELSE  phrase  ENDIF  ‘ ’ 
message : 

[ident  ident  ident  term_list 

property : 

CRYPTO  I  FRESH  I  PRIVATE  I  EXPOSED  I  ASSOC  |  COMM 

term: 

ident 

I 

functioncall 

I 

bracket 

I 

lowe 

I 

paren 

fxinctioncall  : 

ident  ^ ^  term^list  ‘ ^ 

/*  arithmetic  expressions  with  +,  *,  /,  and 

(for  exponentiation)  are  supported,  and 
treated  as  function  calls  on  pis,  mns,  etc.  */ 

bracket : 

term.list  [term]  /♦  single  quote  for  decrypt  */ 

I 

term_list  *]’  [term] 


lowe : 

term  ‘7/  term 
paren: 

term 
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A. 2  CIL  Syntax 


This  is  the  syntax  of  CIL  output  in  functional  notation.  Identifiers  in  quotes 
are  literal  tokens,  as  are  parentheses  and  commas.  Other  identifiers  are 
nonterminals.  We  use  the  ‘Jist’  meta-rule  here  too. 

specification:  ^CILspec^symbols,  slots,  axioms,  assums, 
rules,  goals,  envs) 

symbols:  ‘symbols' (symbol^list) 

symbol:  ‘symbol' (ident,  status,  ids,  ident,  props) 

status:  ‘type'  |  ‘op'  |  ‘var'  |  ‘pvar' 

ids:  ‘ids' (ident.list) 

props :  ‘props' (property.list) 

slots :  ‘ slots ' (slot.list) 

slot :  ‘ slot ' (term,  ident ,  number) 

axioms:  ‘axioms' (stmt^list) 

stmt:  equation  |  term 

equation:  ‘eqn'(term,  term) 

term:  ident  |  fncall 

f ncall :  ident  (term_.list) 

assums:  ‘assums' (loc^list) 

loc :  ‘loc' (nodes,  statement) 

nodes :  ‘nodes ' (node_list) 
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node:  ^nodeHident,  number) 


rules:  'rules ^ (rule.list) 
rule:  'rule’ (facts,  ids,  facts) 
facts:  'facts’ (term.list) 
goals:  'goals’ (loc.list) 
envs:  'envs’ (env_list) 

env:  'environment’ (ident,  agents,  exposed,  order) 

agents :  ' agent ’ (ident ,  eqns) 

eqns:  'eqns’ (equation^list) 

exposed:  'exposed’ (terms (term^list)) 

order :  ' order ’ ( or der spe  c ) 

order spec: 
ident 
I  'allpar’ 

I  ' seq’ (orderspec ,  orderspec) 

I  'par ’ (orderspec,  orderspec) 
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Appendix  B 

The  Prelude 


This  appendix  specifies  the  predefined  types.  The  typespecs  given  here  are 
combined  into  a  file  prelude. cap  that  is  automatically  read  and  imported 
by  the  CAPSL  translator  prior  to  user-supplied  specifications. 


B.l  Basic  and  Boolean 


These  types  are  for  basic  objects  that  are  not  message  fields.  Note  that  there 
is  an  undeclared  ’’Object”  type.  No  axioms  are  given  for  booleans  because 
it  is  assumed  that  any  protocol  analysis  tool  will  have  these  built  in. 

TYPESPEC  BASIC; 

TYPES 

Role,  Spec,  Agent:  Object; 

Tspec,  Pspec,  Espec:  Spec; 

END; 

TYPESPEC  BOOLEAN; 

IMPORTS  BASIC; 

TYPES 

Boolean:  Object; 

CONSTANTS 

true,  false:  Boolean; 

FUNCTIONS 

and(Boolean,  Boolean):  Boolean,  ASSOC,  COMM; 
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or(Booleaii,  Boolean):  Boolean,  ASSOC,  COMM; 

not (Boolean) ;  Boolean; 

if (Boolean,  Boolean,  Boolean):  Boolean; 

END; 


B.2  Field 

The  Field  type  is  the  universal  supertype  for  all  message  fields.  There  is 
a  subtype  Atom  of  Field  for  fields  that  can  be  detached  from  the  left  of  a 
concatenation.  A  type  declaration  with  no  explicit  supertype  implies  a  su¬ 
pertype  of  Atom.  A  Tape  is  a  nonatomic  field;  it  is  a  concatenated  sequence 
of  atoms.  The  ASSOC  property  of  cat  declares  that  it  is  associative  without 
the  need  for  explicit  axioms. 

TYPESPEC  FIELD; 

IMPORTS  BOOLEAN; 

TYPES 

Field:  Object; 

Tape,  Atom:  Field; 

Principal,  Nonce,  Number:  Atom; 

FUNCTIONS 

cat(Field,  Field):  Tape,  ASSOC; 
fir St (Tape):  Atom; 
rest(Tape):  Field; 

VARIABLES 
X:  Atom; 

Y:  Field; 

AXIOMS 

first (cat (X,  Y))  =  X; 
rest(cat(X,  Y))  =  Y; 

INVERT  cat(X,  Y):  X; 

INVERT  cat(X,  Y) :  Y  |  X; 

END; 
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B.3  Symmetric-Key  Encryption 


The  basic  Skey  type  is  used  by  several  sets  of  encryption  operators.  The 
only  operators  given  in  this  root  typespec  are  a  hash  function  and  a  keyed 
hash  (message  authentication  code).  The  DES  system  could  be  modeled 
with  the  se ,  sd  pair.  The  only  form  of  single-operator  symmetric  system 
that  is  commonly  seen  in  practice  is  xor,  given  below. 

TYPESPEC  SKEY; 

IMPORTS  FIELD; 

TYPES  Skey; 

FUNCTIONS 

sha(Field) :  Skey; 
mac (Skey , Field) ;  Skey; 

END; 

TYPESPEC  DSKE; 

IMPORTS  SKEY; 

FUNCTIONS 

se(Skey,  Field):  Field; 
sdCSkey,  Field):  Field; 

AXIOMS 

se(Skey,  Atom):  Atom; 
sd(Skey,  Atom):  Atom; 
sd(K,  se(K,  D))  =  D; 
se(K,  sd(K,  D))  =  D; 

INVERT  se(K,  D) :  D  |  K; 

INVERT  sd(K,  D):  D  I  K; 

END; 

TYPESPEC  XOR; 

IMPORTS  SKEY; 

FUNCTIONS 

xorCSkey,  Skey):  Skey,  ASSOC,  COMM; 

AXIOMS 

xor(xor(K,K) ,K1)  =  Kl; 

INVERT  xor(K,Kl):  K  I  Kl; 

INVERT  xor(K,Kl):  Kl  |  K; 

END; 
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/*  Symmetric  Key  Client,  Server  */ 

TYPESPEC  SKCS; 

IMPORTS  SKEY; 

TYPES  Client,  Server:  Principal; 

VARIABLES 

S  :  Server; 

C  :  Client ; 

FUNCTIONS 

csk(Client):  Skey,  PRIVATE; 

ssk (Server , Client ) :  Skey,  PRIVATE; 

AXIOMS 

ssk(S,  C)  =  csk(C) ; 

END; 

/*  Mutual  S3rmmetric  Key  Node  */ 

TYPESPEC  MSKN; 

IMPORTS  SKEY; 

TYPES  Node:  Principal; 

FUNCTIONS 

msk(Node,  Node):  Skey,  COMM,  PRIVATE; 

END; 

/*  Arithmetic  operations  may  be  used  in  CAPSL  with  the 
infix  syntax  +,  -,  *,  /, 

♦/ 

TYPESPEC  ARITH; 

IMPORTS  SKEY; 

CONSTANTS  1:  Skey; 

FUNCTIONS 

pis (Skey,  Skey):  Skey,  ASSOC,  COMM; 
mns(Skey):  Skey; 

tms(Skey,  Skey):  Skey,  ASSOC,  COMM; 
div(Skey,  Skey):  Skey; 
exp(Skey,  Skey):  Skey; 

/♦ 

AXIOMS 
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*/ 

END; 

B.4  Public-Key  Encryption 


As  in  symmetric-key  encryption,  there  is  a  basic  public-key  type,  used  for 
both  public  and  private  keys.  The  single-operator  version  ped  models  RSA 
at  a  very  abstract  level. 

TYPESPEC  PKEY; 

IMPORTS  FIELD; 

TYPES  Pkey; 

FUNCTIONS 

keypair(Pkey,  Pkey):  Boolean,  COMM; 

END; 

TYPESPEC  SPKE; 

IMPORTS  PKEY; 

FUNCTIONS 

ped(Pkey,  Atom):  Atom; 
ped(Pkey,  Field):  Field; 

AXIOMS 

if  keypair(K,  Kl)  THEN  ped(Kl,  ped(K,  X))  =  X  ENDIF; 
if  keypair(K,  Kl)  THEN  INVERT  ped(K,  X) :  X  I  Kl  ENDIF; 

END; 

/*  PPK  provides  simple  steindaxd  public/private  key  lookup.  */ 

TYPESPEC  PPK; 

IMPORTS  PKEY; 

TYPES  PKUser:  Principal; 

FUNCTIONS 

sk(PKUser):  Pkey,  PRIVATE; 
pk(PKUser):  Pkey; 

AXIOMS 

keypair(sk(P) ,pk(P)) ; 

INVERT  ped(sk(P) ,X) :  X  |  pk(P) ; 

INVERT  ped (pk(P),X):  X  I  sk(P) ; 
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END; 


B.5  Key  Agreement 

This  key  agreement  type  is  meant  to  express  the  basic  properties  of  DifHe- 
Heilman  key  agreement.  The  kap  operation  creates  a  public  value  that  can 
be  combined  with  an  Skey  to  produce  another  Skey  using  kas.  This  type 
specification  omits  significant  relations  that  emerge  when  kap  is  implemented 
by  raising  a  known  base  value  to  the  Skey  power  modulo  a  prime. 

TYPESPEC  KeyAgreement ; 

IMPORTS  SKEY; 

TYPES  Pval; 

FUNCTIONS 

kap (Skey):  Pval; 
kas (Pval,  Skey):  Skey; 

AXIOMS 

kas (kap (Ka), Kb)  =  kas(kap(Kb) ,Ka) ; 

END; 


B.6  Public-Key  Sealing 

The  following  public-key  seal  operation  could  be  implemented  with  a  keyed 
hash,  but  it  may  also  be  viewed  as  a  primitive  operation.  It  could  be  the 
basis  for  a  signature  if  one  assumes  that  the  sealing  key  is  private  to  the 
signer. 

TYPESPEC  PKSeal; 

IMPORTS  PKEY; 

TYPES  Pseal; 

FUNCTIONS 

seaKPkey,  Field):  Pseal; 
verify(Pkey,  Pseal,  Field):  Boolean; 

AXIOMS 

IF  keypair(K,  Kl)  THEN  verif y(Kl ,seal(K,  X),  X)  ENDIF; 

END; 
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B.7  Timestamps 


Timestamps  are  used  simply  by  assuming  that  eaeh  agent  that  generates  or 
checks  a  timestamp  holds  it  initially.  Equality  comparisons  can  be  used  to 
simulate  “nearness.”  A  more  advanced  version  might  check  ordering. 

TYPESPEC  TIMESTAMP; 

TYPES  Timestamp; 

END; 


B.8  List 


The  List  type  support  the  non-associative  concatenation  operator. 


TYPESPEC  LIST; 

IMPORTS  FIELD; 

TYPES  List; 

FUNCTIONS 

conCField,  Field):  List; 
head(List):  Field; 
tail(List):  Field; 

AXIOMS 

head(con(X,  Y))  =  X; 
tail(con(X,  Y))  =  Y; 
INVERT  con(X,  Y):  X; 
INVERT  con(X,  Y) :  Y; 

END; 


B.9  End  Prelude  Marker 

This  type  is  placed  at  the  end  of  the  prelude  to  mark  the  separation  of 
symbols  and  axioms  in  the  prelude  from  those  in  user-supplied  typespecs. 
This  separation  is  helpful  for  connectors  that  provide  built-in  support  for 
the  prelude  types. 

TYPESPEC  ENDPRELUDE; 
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CONSTANTS  endprelude:  Boolean 
AXIOMS 

endprelude  =  true; 

END; 


Appendix  C 


CAPSL  Examples 


This  appendix  contains  two  relatively  complex  examples  of  CAPSL.  The  SSL 
example  illustrates  conditional  selection  of  subprotocols.  The  SRP  example 
illustrates  use  of  arithmetic.  Both  utilize  customized  subtypes  of  Principal. 

C.l  SSL  Handshake 

The  Secure  Socket  Layer  (SSL)  Handshake  Protocol,  version  3,  is  an  Internet 
Draft  that  can  be  found  on  the  Netscape  site,  http :  //home . netscape .  com/ 
eng/ ssl3.  This  CAPSL  example  is  a  partial  version  that  expands  only  one 
of  the  cipher  spec  options,  Diffie-Hellman.  RSA  and  Fortezza-DMS  are 
the  others.  This  version  also  does  not  perform  client  authentication.  For 
simplicity  we  omit  the  cipher  suite  and  compression  method  lists. 

The  CAPSL  text  illustrates  conditional  selection  of  subprotocols  and  the 
DENOTES  section.  The  sha  operator  is  used  wherever  hashes  are  called  for, 
and  much  of  the  detailed  construction  of  hashes  and  key  material  has  been 
simplified.  The  method  for  simplifying  hashes  is  to  include  the  contribut¬ 
ing  data  but  ignore  ordering,  constants,  and  other  details  that  affect  the 
cryptographic  strength  but  not  the  logical  structure  of  the  protocol.  The 
key  agreeement  operators  are  used  instead  of  explicit  exponentiation  in  the 
Diffie-Hellman  exchange,  so  the  base  and  modulus  are  not  mentioned. 

TYPESPEC  SSLS; 

TYPES  CertServer:  PKUser; 
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FUNCTIONS 

T(CertServer) :  Field;  /♦  PK  certificate  */ 
VARIABLES 

Sv:  CertServer; 

CONSTANTS 

CA:  PKUser;  /*  Certificate  Authority  */ 
AXIOMS 

T(Sv)  =  {Sv,pk(Sv)}sk(CA); 

END; 

PROTOCOL  SSLHandshake; 

IMPORTS  SSLS; 

TYPES  Cipher Spec; 

VARIABLES 

C:  PKUser; 

S:  CertServer; 


Rc,Rs:  Nonce,  CRYPTO; 

CS:  CipherSpec; 

/* 

Client/ServerHello. random  */ 

SID:  Nonce; 

/* 

session  id  */ 

PMS:  Skey; 

/* 

pre-master-secret  */ 

MS:  Skey; 

/* 

master  secret  ♦/ 

PKs:  Pkey; 

/* 

Server  public  key  pk(S)  */ 

CONSTANTS 

DH,  RSA,  DMS:  CipherSpec; 

SSLDH,  SSLRSA,  SSLDMS:  Pspec; 

DENOTES 

MS  =  sha({PMS,Rc,Rs}); 

ASSUMPTIONS 

HOLDS  C:  S,  CS; 

MESSAGES 

ClientHello.  C  ->  S:  C,Rc,CS; 

ServerHello.  S  ->  C:  S,Rs,CS; 

ServerCertif icate.  S  ->  C:  T(S)y,{S,PKs}sk(CA) ; 

IF  CS  =  DH  THEN  INCLUDE  SSLDH; 

ELSE  IF  CS  =  RSA  THEN  INCLUDE  SSLRSA; 

ELSE  IF  CS  =  DMS  THEN  INCLUDE  SSLDMS; 

/♦  ELSE  INCLUDE  SSLERR;  ♦/  ENDIF; 

ENDIF;  ENDIF; 

GOALS 

SECRET  MS ; 
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PRECEDES  C:  S  I  MS,Rs,Rc; 


END; 

PROTOCOL  SSLDH; 

IMPORTS  SSLHandshake ; 

VARIABLES 

Yc,Ys:  Pval;  /*  key  agreement  public  values  ♦/ 

Xc,Xs:  Skey,  FRESH , CRYPTO ;  /*  key  agreement  secret  values  */ 
D:  Field; 

MESSAGES 

ServerKeyExchange .  S  ->  C:  kap(Xs)*/,Ys, ({sha(kap(Xs))}sk(S))‘/,D; 

{D>PKs  =  sha(Ys); 

/*  SeverHelloDone .  S  ->  C:  i  }  */ 

ClientKeyExchange .  C  ->  S:  kap(Xc)*/.Yc ; 

PMS  =  kas(Yc,Xs);/ 

PMS  =  kas(Ys,Xc); 

ClientFinished.  C  ->  S:  sha({MS,C}); 

ServerFinished.  S  ->  C:  sha({MS,S}); 

END; 

/*  protocols  SSLRSA,  SSLDMS,  and  SSLERR  would  be  needed  */ 

C.2  Secure  Remote  Password  (SRP)  Protocol 

SRP  is  a  protocol  in  the  EKE  family  designed  to  defeat  password  guessing, 
developed  at  Stanford.  There  is  a  web  site  for  it,  http: //srp. Stanford, 
edu/srp/.  This  CAPSL  specification  incorporates  a  few  modifications  for 
simplicity; 

1.  There  is  no  mention  of  the  modulus  iV  for  finite  field  arithmetic.  Arith¬ 
metic  is  done  on  Skeys. 

2.  The  checks  that  S,u,  and  A  are  not  zero  are  omitted. 

3.  Messages  3  and  4  to  confirm  reception  of  the  key  K  are  simpler  than 
the  suggested  ones. 


TYPESPEC  User; 

TYPES  User,  Host:  Principal; 
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FUNCTIONS 

g:  Skey;  /*  generator  */ 

p(User):  Field,  PRIVATE,  CRYPTO;  /*  password  */ 
s(Host,User) ;  Field,  PRIVATE;  /*  salt  */ 
v(Host,User) :  Skey,  PRIVATE;  /♦  password  verifier  ♦/ 

AXIOMS 

v(Hl,Ul)  =  g“sha({s(Hl,Ul),p(Ul)}); 

END; 

PROTOCOL  SRP; 

IMPORTS  User; 

VARIABLES 
U:  User; 

H:  Host; 

A,  B:  Skey; 

a,  b,  u:  Skey,  FRESH,  CRYPTO; 

K,S,s,x:  Skey; 

DENOTES 

A  =  g'a; 

B  =  v(H,U)  +  g-b; 

X  =  sha({s,p(U)}) ; 

V  =  g"x; 

ASSUMPTIONS 

HOLDS  U:  H; 

MESSAGES 

1.  U  ->  H:  U,  A;  /*  U  generates  a  */ 

S  =  (A*v(H,U)"u)“b;  /*  H  generates  b  ♦/ 

K  =  sha(S); 

2.  H  ->  U:  s(H,U)7.s,  B,  u; 

S  =  (B  -  v)'(a  +  u*x) ; 

K  =  sha(S); 

3.  U  ->  H:  {AH;  /*  proves  U  holds  K  */ 

4.  H  ->  U;  {B}K;  /*  proves  H  holds  K  */ 

GOALS 

SECRET  K; 

END; 
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Appendix  D 

CIL  Output  Example 


This  appendix  shows  the  actual  CIL  output  for  the  NSPK  protocol  with  a 
sample  environment. 


D.l  CAPSL  Specification  for  NSPK 

PROTOCOL  NSPK; 

VARIABLES 

A,  B:  PKUser; 

Na,  Nb:  Nonce,  CRYPTO; 

ASSUMPTIONS 
HOLDS  A:  B; 

MESSAGES 

A  ->  B:  {A,Na}pk(B); 

B  ->  A:  {Na,Nb}pk(A); 

A  ->  B:  {Nb>pk(B); 

GOALS 

SECRET  Na; 

SECRET  Nb; 

PRECEDES  A:  B  I  Na; 

PRECEDES  B:  A  I  Nb; 

END; 

ENVIRONMENT  Testl; 
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IMPORTS  NSPK; 

CONSTANTS 

Alice,  Bob:  PKUser; 
Mallory:  PKUser,  EXPOSED; 
AGENT  A1  HOLDS 
A  =  Alice; 

B  =  Bob; 

AGENT  B1  HOLDS 
B  =  Bob; 

EXPOSED 

{Bob}sk(Alice) ; 

END; 


D.2  CIL  Output  for  NSPK 

This  is  the  CIL  output  from  the  CAPSL  specification  above.  Note  that 
the  prelude  was  incorporated,  resulting  in  many  symbol  table  entries  and 
axioms. 

CILspecC 
symbols ( 

symbol (Obj ect, type, ids 0 , Object, props ())  , 

symbol  (BASIC,  op,  ids  0  ,  Tspec, props  ()) , 

symbol (Role, type, ids  0 ,Object,props()) , 

symbol (Spec, type, ids  0 , Object , props ()) , 

symbol ( Agent , type, ids () , Object , props ()) , 

symbol (Tspec, type, ids  0 , Spec, props ()) , 

symbol (Pspec, type, ids  0 , Spec, props ()) , 

symbol (Espec, type, ids  0 , Spec, props ()) , 

symbol (BOOLEAN, op, ids  0 , Tspec, props ()) , 

symbol (Boolean, type, ids  0 ,Object,props()) , 

symbol (true, op, ids  0 ,Boolean,props()) , 

symbol (false, op, ids  0 ,Boolean,props()) , 

symbol(and,op, ids (Boolean, Boolean) ,Boolean,props() ) , 

symbol (or, op, ids (Boolean, Boolean) ,Boolean,props()) , 

symbol (not , op , ids (Boolean) , Boolean , props () ) , 

symboKif , op,  ids  (Boolean, Boolean, Boolean)  , Boolean, props  ()  )  , 

symbol (FIELD, op, ids  0 , Tspec , props ()) , 
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symbol (Field, type, ids  0 ,0bject , props () ) , 
symbol (Tape, type, ids () ,Field,props()) , 

S5rmbol (Atom, t3rpe, ids 0  ,Field,props()) , 

S3rmbol (Principal, type, ids 0  ,Atom,props())  , 
symbol (Nonce, type, ids  0 ,Atom,props()) , 

S3rmbol (Number, type, ids 0  ,Atom,props()) , 

symbol (cat , op , ids (Field , Field) , Tape , props (ASSOC) ) , 

S3rmbol  (first,  op,  ids  (Tape)  ,Atom,props())  , 

symbol (rest , op, ids (Tape) , Field, props ()) , 

symbol(Al,var ,ids() ,Atom,props()) , 

symbol (XI, var, ids  0 ,Field,props()) , 

symbol (SKEY, op, ids  0 , Tspec, props ()) , 

symbol (Skey, type, ids  0 , Atom, props ()) , 

symbol (sha, op, ids (Field) ,Skey , props ()) , 

symbol (mac , op , ids (Skey , Field) , Skey , props ( ) ) , 

symbol (DSKE, op, ids  0 , Tspec , props () ) , 

symbol ( se , op , ids (Skey , Atom) , At om , props ( ) ) , 

symbol (sd, op, ids (Skey, Atom) , Atom, props () ) , 

symbol ( se , op , ids (Skey , Field) , Field , props ( ) ) , 

symboKsd, op, ids(Skey, Field)  ,Field,props())  , 

symbol (Kl, var, ids  0 , Skey , props ()) , 

symbol (Kll, var, ids  0 ,Skey,props()) , 

symbol (XOR, op, ids  0 ,Tspec,props()) , 

symbol (xor , op , ids (Skey , Skey) , Skey , props (ASSOC , COMM) ) , 

symbol (SKCS, op, ids  0 , Tspec, props ()) , 

symbol (Client , type, ids  0 ,Principal,props()) , 

symbol (Server, type, ids  0 ,Principal,props()) , 

symbol (SI, var, ids  0 ,Server ,props() ) , 

symbol(Cl,var ,ids() , Client ,props() ) , 

S3rmbol  (csk ,  op ,  ids  (Client )  ,  Skey ,  props  (PRIVATE)  )  , 

symbol ( s  sk , op , ids (Server , Client ) , Skey , props (PRIVATE) ) , 

symbol (MSKN, op, ids  0 ,Tspec,props()) , 

symbol (Node , type , ids ( ) , Principal , props ( ) ) , 

symbol (msk , op , ids (Node , Node) , Skey , props (COMM , PRIVATE) ) , 

symbol ( ARITH, op, ids  0 ,Tspec,props()) , 

symbol (1, op, ids  0 ,Skey ,props()) , 

symbol (pis , op , ids (Skey , Skey) , Skey , props (ASSOC , COMM) ) , 
symbol (mns , op, ids (Skey) , Skey, props ()) , 
symbol (tms, op, ids (Skey, Skey) , Skey , props (ASSOC, COMM)) , 
symbol (di v , op , ids ( Skey , Skey) , Skey , props ( ) ) , 
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symbol (exp , op , ids (Skey , Skey) , Skey .props () ) , 
symbol (PKEY, op, ids 0  .Tspec.propsO)  , 
symbol (Pkey, type, ids  0 ,Atom,props() ) , 
symbol (PKl , var , ids ( ) , Pkey , props ( ) ) , 
symbol (PKIl.var, ids  0 , Pkey .props ()) , 

symbol (keypair, op, ids (Pkey, Pkey) ,Boolean,props(COMM)) , 

symbol (SPKE, op, ids 0  .Tspec.propsO)  , 

symbol (ped, op, ids (Pkey, Atom) ,Atom,props()) , 

symbol (ped, op, ids(Pkey, Field) ,Field,props()) , 

symbol (PPK, op, ids 0  .Tspec.propsO)  , 

symbol (PKUser, type, ids  0 , Principal, propsO) , 

symbol (sk, op, ids (PKUser) ,Pkey,props (PRIVATE) ) , 

symbol (pk, op, ids (PKUser) ,Pkey,props()) , 

symbol (PKUl, var, ids  0 .PKUser .props ()) , 

symbol (KEY AGREEMENT, op, ids  0 .Tspec.propsO) , 

symbol (Pval, type, ids  0 ,Atom,props()) , 

symbol (kap, op, ids (Skey) ,Pval,props()) , 

symbol (kas , op , ids (Pval , Skey) , Skey , props () ) , 

symbol (PKSeal, op, ids 0  .Tspec.propsO)  , 

symbol (Pseal, type, ids  0 ,Atom,props()) , 

symbol (seal, op, ids (Pkey, Field) , Pseal, props ()) , 

symboKverify, op, ids(Pkey, Pseal, Field) ,Boolean,props()) , 

symbol  (TIMESTAMP,  op,  ids  0  .Tspec.propsO)  , 

symbol (Time stamp, type, ids  0 ,Atom,props()) , 

symbol  (LIST,  op,  ids  0  .Tspec.propsO) , 

symbol (List, type, ids  0 , Atom, props O) , 

symbol  (con,  op,  ids  (Field,  Field)  .List.propsO)  , 

symbol (head, op, ids (List) ,Field,props()) , 

symbol(tail,op,ids(List) .Field, props ()) , 

symbol (XI, var, ids  0 ,Field,props()) , 

symbol (Yl, var, ids  0 ,Field,props()) , 

symbol (ENDPRELUDE, op, ids 0  .Tspec.propsO)  , 

symbol (endprelude , op , ids 0 ,Boolean,props()) , 

symbol (NSPK, op, ids  0 .Pspec, props ()) , 

symbol (A , pvar , ids ( ) , PKUser , props  0 ) , 

symbol (B.pvar, ids O ,PKUser,props()) , 

symbol (Na,pv2or, ids  0 .Nonce, props (CRYPTO, FRESH)) , 

symbol (Nb, pvar , ids 0 .Nonce, props (CRYPTO, FRESH)) , 

symbol (Test 1, op, ids  0 ,Espec .props ()) , 

symbol (Alice, op, ids 0 .PKUser .props ()) , 
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symbol (Bob, op, ids 0 ,PKUser,props()) , 

symbol (Mallory, op, ids () ,PKUser , props (EXPOSED) ) , 

symbol (Al, op, ids  0 .Agent, props ()) , 

S3rmbol(Bl ,op,ids()  , Agent, pr ops ())  , 
symbol (roleA, op, ids  0 ,Role,props() ) , 
symbol (roleB, op, ids  0 ,Role, props ()) , 
symbol (UNK ,pvar , ids () .Principal .props () ) 

), 

slots ( 

slot ( A, roleA, 1) , 
slot (B, roleA, 2) , 
slot (B, roleB, 1) , 
slot (Na, roleA, 3) , 
slot(A,roleB,2) , 
slot (Na, roleB, 3) , 
slot (Nb , roleB , 4 ) , 
slot (Nb, roleA, 4) 

). 

axioms ( 

eqn(first(cat(Al,Xl)) ,A1) , 
eqn(rest(cat(Al,Xl)) ,X1) , 
invertible (cat (Al, XI) ,Al,terms()) , 
invertible (cat (Al, XI) ,Xl,terms()) , 
eqn(sd(Kl,se(Kl,Xl)) ,X1) , 
eqn(se(Kl,sd(Kl,Xl)) ,X1) , 
invert ible(se(Kl, XI) , XI, terms (Kl)) , 
invertible(sd(Kl,Xl) , XI. terms (Kl) ) , 
eqn(xor(xor(Kl,Kl) ,K11) ,K11) , 
invertible(xor(Kl,Kll) ,Kl,terms(Kll)) , 
invertible  (xor(Kl, KID, Kll,  terms  (KD), 
eqn(ssk(Sl,Cl) ,csk(Cl)) , 

if (keypair(PKl,PKIl) ,eqn(ped(PKIl,ped(PKl,Xl)) ,X1) .true) , 
keypair(sk(PKUl) ,pk(PKUl)) , 

invert ible(ped(sk(PKUl) ,X1) , XI, terms (pk (PKUl))) , 
invertible (ped(pk(PKUl) ,X1) ,Xl,terms(sk(PKUl))) , 
eqn(kas(kap(Kl) ,K11) ,kas(kap(Kll) ,K1) ) , 
eqn(keypair(PKl,PKIl) ,verify(PKIl,seal(PKl,Xl) ,X1)) , 
eqn(head(con(Xl,Yl)) ,X1) , 
eqn(tail(con(Xl,Yl)),Yl), 
invertible (con(Xl,Yl) ,Xl,terms()) , 
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invertible (conCXl.Yl) ,Yl,terms()) , 
eqnCendprelude .true) 

), 

assumsdoc (nodes (node (roleA,0) ,node(roleB,0)) ,holds(A,ids(B)))) , 
rules ( 

rule(facts() ,ids() ,facts(state(roleA,0,terms(A,B)))) , 
rule (facts () ,idsO ,facts(state(roleB,0,terms(B)))) , 
rule( 

facts (state (roleA , 0 , terms ( A , B) ) ) , 
ids(Na) , 

f acts (state (roleA, 1, terms(A, B, Na) ) ,msg(A,B, terms (ped(pk(B) ,cat(A,Na))))) 

), 

rule( 

facts(state(roleB,0, terms (B)) ,msg(UNK,B, terms (ped(pk(B) ,cat(A,Ka))))) , 
ids(Nb) , 
facts ( 

state(roleB,2,terms(B,A,Na,Nb)) , 
msg (B , A , terms (ped (pk (A),cat(Na,Nb)))) 

) 

), 

rule( 
facts ( 

state(roleA,l,terms(A,B,Na)) , 

msg (UNK , A , terms (ped (pk (A),cat(Na,Nb)))) 

), 

idsO , 

facts (state (roleA, 3, terms (A, B,Na,Nb)) , msg(A, B, terms (ped(pk(B) ,Nb)))) 

). 

rule( 

facts(state(roleB,2,terms(B,A,Na,Nb)),msg(UNK,B,terms(ped(pk(B),Nb)))) , 

idsO  , 

f  acts (state (roleB , 3 , terms (B,A,Na,Nb))) 

) 

), 

goals ( 

loc (nodes (node (roleA, 3) ,node (roleB, 3) ), secret (Na, idsO)) , 
loc (nodes (node (roleA, 3) , node (roleB, 3)) , secret (Nb, idsO)) , 
loc (nodes (node (roleA, 3) , node (roleB, 3)) ,precedes(A,B,ids(Na) )) , 
loc (nodes (node (roleA ,3) ,node (roleB , 3) ) , precedes (B , A , ids (Nb) ) ) 

), 
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envs( 

environment  ( 

Testl , 
agent s( 

agent(Al,eqns(eqn(A, Alice) ,eqn(B,Bob))) , 
agent (B1 , eqns (eqn(B , Bob) ) ) 

), 

exposed(terms(ped(sk(Alice) ,Bob))) , 
order (allpar) 

) 

) 
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MISSION 

OF 

AFRL/INFORMATION DIRECTORATE  (IF) 


The  advancement  and  application  of  Information  Systems  Science 
and  Technology  to  meet  Air  Force  unique  requirements  for 
Information  Dominance  and  its  transition  to  aerospace  systems  to 
meet  Air  Force  needs. 


